On Thu, Mar 27, 2014 at 1:40 PM, Sven Panne <[email protected]> wrote: > We will continue to improve the whole API, especially regarding the > confusing notions of "default Isolate" and "current Isolate". In the future, > as a rule of thumb, an embedder should be prepared to have an explicit > Isolate at hand when one is needed, and you have to care for the > creation/destruction of Isolates explicitly. Magically creating a VM > instance before main() and relying on thread-local storage all over the > place is a constant source of bugs and confusion. Making the VM lifetime > explicit and having no notion of TLS in v8 will greatly simplify and > robustify things. This is how it should have been done in the first place, > but given the complexity of our code and the code of our embedders, the > transition is not easy and will take some time.
I cheer you on from the sidelines but I have to point out that moving away from thread-local storage will irredeemably break the popular node-fibers module[1] (used in Cloud9 IDE[2], Meteor[3], etc., not to mention thousands of in-house applications.) Its "fibers" (coroutines) work by saving and restoring V8's thread-local state whenever the fiber yields. That tricks V8 into thinking that it runs in another system thread and that allows multiple concurrent (if not parallel) threads of execution. It's a terrible hack but hey, it _does_ work. I'm not saying that's a reason to stop improving V8 but I'm sure many people would appreciate a way going forward. [1] https://github.com/laverdet/node-fibers [2] https://c9.io/ [3] https://www.meteor.com/ -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
