Hi Slava, Slava Pestov wrote: > [...] > As we discussed in the channel, a potentially cleaner approach would > be to put all global VM state in a struct (or a series of structs) > instead of making them thread-local variables. Then you can either > pass this struct around, or store it in a single thread-local > variable. >
Sounds reasonable, although modifying all the calls to populate and pass vm structures around may bloat the code a bit. > [...] > Finally, it would be easy to add a 'VM lock' which would allow the > possibility of spawning a Factor co-operative thread in a new native > thread. FFI calls would release the lock. This wouldn't enable > multiprocessing but it would allow non-blocking FFI calls to take > place, as well as callbacks from threads other than the primary > thread, and eliminate the need for the VM's stdin thread hack. Of > course by default, the in-thread combinator and similar would still > spawn a co-operative lightweight thread; you'd only use the native > threads for FFI calls and such. So you mean a per-VM lock rather than a python style GIL? That would be interesting. I guess each thread would need to know the vm it belonged to so it could obtain the right lock. > To make your multiple-VM-threads feature more usable, you could work > on setting up some communication channels between multiple VMs in a > single process. Then you can shoehorn concurrency.distributed to use > this facility, allowing semi-transparent passing of Factor data > between threads. > Yep I was thinking along these lines. A concurrent queue per vm and using the serialization library to pass stuff around. (I haven't spent much time thinking about this so there's probably better ways) > [ ... ] > As for 1.0 I really do want to release it soon as possible. Basically > my plan is that after I finish with some compiler changes, I want to > make another formal release; let's say 0.92; and from that point on, > pretty much focus just on bug fixing and documentation. > > If people help out, some of the above threading-related changes could > make it in, too. > I'd like to at least get the VM reentrant. Personally I need to get access to a windows environment so I can make the reentrancy stuff portable. Windows people (Doug?): Does anybody have experience writing threaded code for windows? Should I use the win32 pthreads wrapper (http://sourceware.org/pthreads-win32/) or the native windows thread api? Cheers, Phil ------------------------------------------------------------------------------ _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
