On Fri Mar 18 19:23:13 EDT 2011, cinap_len...@gmx.de wrote:
> theres a first attempt of a parallel dial implementation that doesnt
> need shared memory to coordinate the the spawning:
>
> /n/sources/contrib/cinap_lenrek/dial.c
>
> it will run at maximum Maxconcurr connects in parallel at a time
>
theres a first attempt of a parallel dial implementation that doesnt
need shared memory to coordinate the the spawning:
/n/sources/contrib/cinap_lenrek/dial.c
it will run at maximum Maxconcurr connects in parallel at a time
until there are no more addresses to connect to left, a connection
is est
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
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
the problem is that libthread procs are just threads running in a
separate plan9 proc, but still have ther stacks on the heap and not in
the plan9 stack segment. so even iodial() will break with the new
multidial implementation.
--
cinap
--- Begin Message ---
Such programs need to be changed to u
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.
correction: you can't do RFMEM|RFPROC. RFPROC alone should work as long as
your current stack is not shared between the two processes.
i see some possible ways to implement multidial() without sharing memory
between the call workers and the caller of the dial().
use the waitmsg or a pipe to sign
what about libthread programs that call dial from a shared threads
stack? you can't call rfork(RFPROC) there.
--
cinap
--- Begin Message ---
Now that the world at large is waking up to IPv6, one problem I kept
tripping over is that dial(2) tries addresses serially, and since it's
not unusual for
good deal. thanks, geoff. i look forward to trying this
out.
one problem i've kept tripping over is a purely internal
and mechanical one. ndb doesn't ever refresh its databases
line. this is a problem at coraid, since each engineer has
a /120 network, and a ndb file to match (this facilitates
