ZeroMQ has a non-blocking mode. You can get a file descriptor that can be passed to select/epoll/kqueue. Factor has its own channel and serialization system to. See:
<http://docs.factorcode.org/content/article-remote-channels,remote-channels.html> On Sun, Oct 19, 2014 at 4:30 AM, Andrea Ferretti <ferrettiand...@gmail.com> wrote: > Thank you for you response. Regarding the possibility if delegating > CPU intensive tasks to multiple tasks: what about communication? Is > there an idiomatic way to make processes communicate without blocking? > There is ZeroMQ, but as far as I know it is blocking. It would be nice > to develop something like Erlang/Akka using a pool of processes and > cooperative multithreading locally inside each process, but I am not > sure what would be the best way to keep a channel among processes > > 2014-10-15 14:40 GMT+02:00 Björn Lindqvist <bjou...@gmail.com>: >> 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 > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
