On 12/30/12 4:57 AM, "Michael Schmalle" <apa...@teotigraphix.com> wrote:
>
> Quoting Alex Harui <aha...@adobe.com>:
>
>>
>>
>>
>> On 12/29/12 8:52 AM, "Michael Schmalle" <apa...@teotigraphix.com> wrote:
>>
>>> I know when I wrote ASDoc, I was able to resolve everything but I used
>>> the MXML compiler as a base. I just need to really understand what is
>>> going on now. I takled the multithreading in FalconJx, but when I
>>> debug, the multithreading is over after;
>>>
>>>
>>> final File outputFolder = new File(outputFile.getParent());
>>> List<ICompilationUnit> reachableCompilationUnits = project
>>>
>>> .getReachableCompilationUnitsInSWFOrder(ImmutableSet
>>> .of(mainCU));
>>>
>>> Once this returns I swear it's synced back on 1 thread. After that
>>> call I loop through all reachable units and produce .js files for each.
>> Interesting. I agree by the time you get here we're back on one thread.
>> But I'm pretty sure the reducers and emitters have been called at least for
>> some threads by then.
>>
>> I hadn't noticed that was when you were starting your tree walk for
>> FalconJx. I thought you were walking in response to the abcbytes request,
>> but I'm pretty sure when I'm debugging FalconJS, that happens while many
>> threads are spinning.
>
> Yes, this is true. I spent 2 hours on this now and have figured it out.
>
> Really, I think there are multiple ways you can implement things here.
> With the current FalconJS they utilized the existing production
> framework.
>
> Honestly, the way I first did it, I don't see a real problem with it
> other than not using the multiple threads to create the actual
> javascript source code (String) like I am doing.
Yes, I agree you will get correct output by waiting until the threads are
done, but then are you going to create degenerate reducers/emitters so you
don't spend time creating ABC instruction lists which is what the threads
seem to be doing? Otherwise, you will be inefficient by whatever time is
spent generating ABC.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
