[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