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

Donald Anderson dda at ddanderson.com
Fri Sep 5 06:55:45 PDT 2008


Good point.  Let's remove the unknowns.

On Sep 4, 2008, at 10:55 PM, Henry Minsky wrote:

> Looking at the flex compiler code, there are a bunch of other state  
> vars that I don't have
> any idea what they do, and which all use this ThreadLocal mechanism:
>
> public final class ThreadLocalToolkit
> {
>
>     private static ThreadLocal<Logger> logger = new  
> ThreadLocal<Logger>();
>     private static ThreadLocal<PathResolver> resolver = new  
> ThreadLocal<PathResolver>();
>     private static ThreadLocal<Map<String, VirtualFile>> resolved =  
> new ThreadLocal<Map<String, VirtualFile>>();
>     private static ThreadLocal<Benchmark> stopWatch = new  
> ThreadLocal<Benchmark>();
>     private static ThreadLocal<LocalizationManager> localization =  
> new ThreadLocal<LocalizationManager>();
>     private static ThreadLocal<MimeMappings> mimeMappings = new  
> ThreadLocal<MimeMappings>();
>     private static ThreadLocal<ProgressMeter> progressMeter = new  
> ThreadLocal<ProgressMeter>();
>     private static ThreadLocal<CompilerControl> compilerControl =  
> new ThreadLocal<CompilerControl>();
>     private static ThreadLocal<StandardDefs> standardDefs = new  
> ThreadLocal<StandardDefs>();
>
> So I'm thinking to be safe maybe I had better make sure each  
> invocation of the
> flex compiler is inside of a new thread.
>
>
> On Thu, Sep 4, 2008 at 10:40 PM, Donald Anderson  
> <dda at ddanderson.com> wrote:
> Yes, I would think tomcat would have a thread pool.
> But -- actually if you look at the function, I don't think exitval
> is actually used for anything important, so that call could be  
> removed.
> The state of the compilation is measured by whether the output file  
> is produced.
>
> On Sep 4, 2008, at 8:44 PM, Henry Minsky wrote:
>
>> Maybe I should have the callJavaCompileCommand method call the flex  
>> compiler
>> in 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
>
>
>
>
>
>
> -- 
> 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/8c40b55d/attachment.html


More information about the Laszlo-dev mailing list