[Laszlo-dev] For Review: Change 20080904-hqm-J Summary: call flex compiler classes directly from jar file

[Donald Anderson]

I would tend to agree.  For one thing, it looks like we'd need to  
configure the java vm for
tomcat with an extra amount (surely it can't be 300K??) just in case  
they use the SWF9 compiler.
If you happen to do development on a machine with 1G or less of  
physical memory,
you could have a lot of thrashing.

On Sep 5, 2008, at 4:03 AM, P T Withington wrote:

> At the very least.  I am still campaigning for it to be called in a  
> separate process because:
>
> + The server is a long-running process that has to maintain state
>
> + The compiler is a task that does not maintain state from one  
> invocation to the next
>
> Hence the compiler is an excellent candidate for 'unix GC', i.e.,  
> use a process to reclaim all resources when the task is done.  That  
> ensures the compiler will not jeopardize the server's uptime.
>
> There is the issue of ensuring that the compiler process must run  
> 'headless' so that it does not throw up a bogus window/task-bar  
> entry (which is the default thing for a java process to do).
>
> On 2008-09-04, at 20:44EDT, Henry Minsky wrote:
>
>> Maybe I should have the callJavaCompileCommand method call the flex  
>> compilerin
>> a new thread??
>>
>>
>>
>> On Thu, Sep 4, 2008 at 8:43 PM, Henry Minsky <hminsky at laszlosystems.com 
>> >wrote:
>>
>>>
>>>>
>>>> 2)
>>>> +        exitval =  
>>>> flex2.compiler.util.ThreadLocalToolkit.errorCount();
>>>> Couldn't find any doc for ThreadLocalToolkit.  Are the errors  
>>>> additive,
>>>> or will they be reset to 0 on each call into the compiler?  (i.e.  
>>>> I'm
>>>> worried about an error being 'sticky' to the next compile - I guess
>>>> it would only result in a stray FAIL println to the error console).
>>>>
>>>
>>> The ThreadLocalToolkit class has a flex Logger object, which is  
>>> stored
>>> within a ThreadLocal
>>> object, which is a Java thing that creates local vars which are  
>>> unique to a
>>> thread.  The Logger object
>>> holds the error count. So as long as each compile is done in a new  
>>> thread,
>>> the error count
>>> will get reset. Now, the question is whether each compile actually  
>>> does
>>> happen in a new thread. I
>>> bet Tomcat has some kind of a thread pool, so I wonder if this is  
>>> going to
>>> cause confusion
>>> at some point.
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> -- 
>> Henry Minsky
>> Software Architect
>> hminsky at laszlosystems.com
>


--

Don Anderson
Java/C/C++, Berkeley DB, systems consultant

voice: 617-547-7881
email: dda at ddanderson.com
www: http://www.ddanderson.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20080905/64ff3960/attachment-0001.html