thinking about it more... all what needs to be parallelized is the write of the connect message so no backchannel is needed except for reporting error/success (already done with the waitmsg in geoffs implementation).
so it looks quite doable without any shared memory. still, might take some time to come up with a small and clean implementation. so what are you going todo for now geoff? a lib9p like forker that gets filled in by libthread is kind of a overkill. also the code would need rewriting as you cant preserve rfork semantics with shared stacks (you need to pass a function pointer and arguments because the child has to run on a new allocated stack). -- cinap
--- Begin Message ---On Thu Mar 17 17:01:51 EDT 2011, ge...@plan9.bell-labs.com wrote: > Such programs need to be changed to use a proc rather than > a thread for dialing (or linked with the old version of dial.c > temporarily). Sorry. i suppose that one could trot out an old trick and do static int (*_dialrforkimpl)(int) = rfork; int _dialprocrfork(int) { procrfork(...); } and let the thread library set this up, along with the few other library functions that need to be overridden? - erik
--- End Message ---
