Slava Pestov wrote: > Phil, > > I think you're jumping the gun here. "GIL"-style threading will > require extensive changes to the VM. A first step is to move > co-operative thread scheduling out of the library and into the VM. > Second, we need to remove the ability to pass byte arrays to FFI > functions (since FFI calls release the lock, any other Factor thread > can come along and run a GC, moving the byte array), and update all > usages of the FFI for this. I'd prefer to do these changes myself.
Of course, but you did ask me to look at this: http://bespin.org/~nef/logs/concatenative/09.10.16 07:48:08 <slava> did you want to investigate platform-specific locking primitives for the vm, and some more thread control wrappers maybe? 07:48:22 <slava> like, how would compiled factor code release the GIL right before an ffi call, etc 07:48:52 <phildawes> ok > Instead, maybe you could finish what you started with multi-VM > threading. The VM startup/shutdown APIs need to be redone and cleaned > up (Doug's work is a good first approximation). There needs to be easy > APIs for spawning new VMs from the Factor side (passing in a > quotation; a list of command line args doesn't cut it). There needs to > be easy ways of communicating between VMs with serialized objects. > Yep. It's the latter I'm looking at at the moment, which requires native-thread notifications for message delivery (I think) and is iirc how we got onto the topic of a factor GIL. Cheers, Phil ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
