No native mutex is needed if you have a pair of pipes between every two VMs that need to communicate. Then, one VM thread writes to the pipe, another VM thread reads from it. Since a VM thread is so heavy-weight (it has its own data heap) opening a handful of pipes is nothing.
What you do need for correct semantics though is a lightweight lock for co-operative threads (using the existing concurrency.locks), to avoid the following race condition: - co-operative thread A wants to send message to co-operative thread C in VM Y - co-operative thread A writes message to pipe - co-operative thread A yields because its doing blocking I/O - co-operative thread B begins running - co-operative thread B wants to send message to co-operative thread D in VM Y - VM-thread X writes message to pipe, now two messaged are interleaved To solve this you need to ensure that if a co-operative thread yields while sending a message to a given VM, no other thread can send a message before it is done, and a lock will accomplish exactly this. Slava On Fri, Oct 23, 2009 at 8:21 AM, Phil Dawes <p...@phildawes.net> wrote: > Makes sense. I was hoping to just pass an fd/Handle on vm startup but I > guess an alien address to a FD/mutex pair isn't much different. I'd have > to do the same for a malloc'd message queue anyway. ------------------------------------------------------------------------------ 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 Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
