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

[P T Withington]

Sticking all your global state in thread-local storage is what you  
have to do if you want your jar to be re-entrant and you are not  
willing to put it in its own process, right?

On 2008-09-04, at 22:55EDT, Henry Minsky wrote:

> Looking at the flex compiler code, there are a bunch of other state  
> vars
> that I don't haveany 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
>> 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
>>
>>
>>
>>
>
>
> -- 
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com