New pthread should not duplicate VFS memory

[mbolt35]

If I create an embedable VFS of significant size (ie: 128mb), and then create a new pthread, memory consumption will increase 128mb, and an additional 128mb for each pthread created after that.

Based on my reading here: https://github.com/adobe-flash/crossbridge/wiki/The-memory-usage-of-threads , the non-domain memory is copied each time a pthread is created. Since any file IO operations are thunked back to the main thread, there is no reason the file system should ever be copied. Additionally, the VFS is made up of mostly ByteArrays, which are sharable between workers, which I would assume would also be exempt from being copied.

This single issue renders pthreads useless in a real application/game which requires the use of a VFS.

Because there is no obvious reason for any ByteArray objects in the AS3 domain to ever be copied, I would definitely label this as a major bug.

[cbakgly]

Oh, this hurts :'(. But I agree somehow, if you have a better idea with less effort.

[liaocheng]

Hi, if you embed the assets to the main swf, it's really hard to separate the assets from the main swf because we just simply creates a new worker as a thread by passing the whole main swf into "createWorker" function

[mbolt35]

Thanks for your responses. I did notice that if I use a web based VFS, because those assets are downloaded at runtime, they're not copied into each Worker. This is better, but it still makes little sense to me why a pthread created via c++ code would ever need any of the inital swf data copied into the worker. I was under the impression that any inline AS3, file io, etc.. was all marshalled back to the main thread, which would mean the data copied into the Worker is never used, and the overhead for a thread increases with the size of the SWF. From a quick glance at the code, it appears that the main application loader bytes are used because it already has the "receiver" code compiled for communicating back to the main thread in regards to the domain memory.

If the above reason is the only reason why this is done, wouldn't it be much more efficient to create a lightweight SWF containing only what was needed to communicate with the main thread, and nothing else? Then, re-use that SWF as the basis for creating new "pthreads"?

Edit: I forgot about the AS3::local namespace which will use the current thread context for as3 interop. While I think it's a good feature to have, perhaps it should be configurable as a build option. It might just be my narrow perspective, but I can think of many cases where threads are more likely to be useful sharing domain memory, rather than sharing copied AS3 objects.

[inspirit]

i totally agree that threads created on native side is usually used for some processing relying on shared memory only and do not use any of as3 objects at all...

[rtissera]

I totally agree this is a show-stopper for me on using pthreads in Crossbridge.