Kyle Huey wrote: > 1. Dealing with the different ownership model on worker threads > (no cycle collector, all owning references go through JS). > 2. Dealing with things that are not available off the main thread > (no necko, no gfx APIs, etc).
FWIW, I think the networking team has a goal of allowing nsHttpChannel to be used off of the main thread, for performance reasons. Not sure on the timeline for that though. > - *Does this mean cycle collected objects can be multithreaded?* > No-ish. > All cycle collected objects will belong to one and only one > thread, and can only be AddRefed/Released on that thread. At what point during XPCOM shutdown are workers destroyed? This seems like a great tool for implementing the worker part of the W3C WebCrypto API. But, we have to deal with the fact that during XPCOM shutdown, we have to ensure all the crypto objects are destroyed, and that has to happen on the main thread. (We're notified about shutdown on the main thread and we have to finish destroying all the objects before we return from the notification.) So, it seems like we may need some kind of "Destroy all the workers" API that deals with this, if we don't have it already. Cheers, Brian _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
