Hi Paul Paul Moore wrote: > > Hmm, this is really far more complex than I can follow, but rather > than using factor-level pipes, why not create pure win32 handle level > pipes, then wrap them using opened-file in the target VM only? That > way, the completion port is only assigned and registered in the > correct VM. >
Yes that's what I'm currently doing. The problem is that this only works for one target vm and I need it to work for many clients. (i.e. currently only one vm can be listening to the IOCompletionPort on the write handle). I'm going to have a bit of a play tonight to see if there's a way round this. > > PS Sorry if this is going down the wrong track. I'm still not > completely sure how the pipe stuff would work at a user level. There's > no example in native-thread-test.factor (for obvious reasons, I > guess...). Could you give a quick example of how user code would > ultimately use this feature? > User api will be something like: : spawn-vm ( quot -- msg-node ) i.e. you pass it a quot to execute in the new vm and it returns a concurrency.messaging node that you can send messages to. Under the hood the spawn-vm call initialises the vm pipe (if it's not already created) spawns a new vm in a native thread and passes it the 'write' end of the pipe and a lock. The new vm thread initialises its own pipe, and pushes the write end of this new pipe down the parent pipe to the parent. Meanwhile both vms spawn a coop thread to continually read their pipe and dispatch messages to local coop threads in the same manner as concurrency.distributed. Hope that makes sense, 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
