Can I use ANE to...

[Adrien_]

Could I used Air Naitive Enxtensions on the Dekstop to tap into the computers ability, through use of Java, to multi thread an application or add multithreading to an application? I understand that Adobe plans to build concuncurrency into flash runtime sometime in the next 10-15 years (exsaggeration), how ever I am wondering if I could use ANE to do this?    

[DaveCates]

Yeah you could do but, as the host app (built in AS3) would not be multi-threaded then surely the overall app would only be psuedo multi-threaded?

Would obviously work for off loading processing that would benefit from multi-threading though - like media (video etc) encoding and processing etc.

[Adrien_]

I was thinking about off loading file handeling processes such as opening, reading, writing, loading contents of a file -while still keeping the UI active.....I really want the AS3 Worker API to be released >_>

[DaveCates]

So, the async and sync file features in Air aren't enough?

You must be manipulating very large files?

Using events with the File features of Air has always been enough for my projects - doesn't let the UI hang too bad while processing - nowhere near enough for a user to detect anyway.

As far as I understand, using ANE won't give you any benefits really since the host AS3 project isn't multi-threaded. Will be psuedo as I said before though since you can use the events between the ANE and AS3 to create an app that behaves a little like it would if mult-threaded.

[DaveCates]

Read here:

http://www.adobe.com/devnet/air/articles/extending-air.html

Specifically the psuedo multi-threading approach I mentioned above is what the author talks about as an approach:

Threading

Native code is permitted to use any available platform threading facilities. This means that extensions can be used, among other things, to improve application responsiveness by moving long-running tasks off of the ActionScript execution thread. However, access to the runtime extension API is allowed, with one exception, only from the same thread on which the runtime invokes the extension. (Note that the runtime doesn't make any guarantees about which thread it will use to invoke the extension.)

If you do use an extension to move work to a background thread, there's a straightforward pattern you can use to work with this restriction:

1. Upon invocation from ActionScript, gather all the data that's needed and save copies in native data structures.
2. Spin up or acquire a thread to perform the work, and hand it the copied data.
3. Upon completion, store the results to a native data structure, and notify ActionScript (see below).
4. When ActionScript receives the completion notification, call into the extension a second time to retrieve the results, which are copied out of the result data structure.

The signaling mentioned in Step 3 is accomplished by calling FREDispatchStatusEventAsync (C) or FREContext.dispatchStatusEventAsync (Java). This call is the one exception mentioned above; it can be called from any thread at any time after the corresponding context is fully initialized.

When this signaling API is called, it causes a StatusEvent, with the specified code and level, to be queued for dispatch in ActionScript at the next opportunity. Typically, this means the event will be dispatched within one frame. The event is dispatched by the corresponding ExtensionContext object. At this point, since execution is by definition back on the ActionScript thread, it's safe (although optional) to call back into native code.