Hi Andrea, I'm not an expert, so take what's written below with a grain of salt. It mostly comes from what I've snapped up from varius places and reading the mailing list archive (eg http://search.gmane.org/?query=threading&group=comp.lang.factor.general&sort=relevance).
2014-10-13 18:14 GMT+02:00 Andrea Ferretti <ferrettiand...@gmail.com>: > Hi, I have read in various places, including this mailing list, that > Factor does not currently have support for (preemptive, kernel-level) > multithreading, and that adding support for that would require a great > deal of changes, since the underlying VM and many core words are not > thread-safe. It's true that Factor doesn't have preemptive, kernel-level threading (I'll just write "threading" from now on when I refer to this particular brand of threading) and that adding it would probably require a lot of engineering and restructuring work. But if you dig into the source, and read the previous discussions, it's clear that adding threading was always the idea and the Factor VM has been architected to make it simple to add in the future. Whether it actually is simple or not, is a different matter. But it's much different from, say, the CPython VM which is implemented in such a way that it would be virtually impossible to add threading. Most composite (non-primitive) words are thread-safe and the primitive words are only "thread-unsafe" in that critical sections aren't guarded by exclusion locks. > Can anyone expand on this? Is there some place where people have > collected some ideas about the issues that would arise and the areas > that need work? I don't think there is any particularly bloody issues. It's just a lot of hard work. For example interactions between threads and gc can be very tricky. If two threads need to allocate memory, there needs to be some synchronization so that they don't end up pointing to the same chunk of memory. How do you make that both fast and safe? What happens with a threads object references if another thread forces a gc cycle? I guess all threads has to stop running during the gc so that all object references can be updated. It's even more complicated if one thread is in an ffi function which holds a pointer to a Factor object. What if another thread recompiles the same word a thread is running? > If not, it would be nice to gather such information from people > knowledgeable about the internals of factor, so that interested people > could start make some contributions. > > I don't know if personally I would be able to contribute, but I'd love > to if I I found something I could handle An alien wrapper for pthreads would be interesting. I've no idea if it would kind of work or break Factor badly, non-the-less it would be interesting to see. While we're at the subject of threading.. It's a great feature but a language VM can do without it and still be very useful. Python, Erlang, Node.js and Ruby all proves that. If the goal of the concurrency is IO throughput, then cooperative threads which Factor already has works really well. For cpu intensive tasks you can often start multiple processes instead of threading. -- mvh/best regards Björn Lindqvist ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
