oc(2), or to
create procs explicitly to do the dial I/O.
Sape
> From: lejat...@gmail.com
> To: 9fans@9fans.net
> Reply-To: 9fans@9fans.net
> Date: Thu Sep 10 11:38:50 CES 2009
> Subject: [9fans] dial and time out
>
> Hello 9fans,
>
> I have a bunch of threads, sim
, ...)
}
}
to send what was read to a central-proc's worker thread.
Sape
> From: lejat...@gmail.com
> To: 9fans@9fans.net
> Reply-To: 9fans@9fans.net
> Date: Thu Sep 10 11:57:50 CES 2009
> Subject: Re: [9fans] dial and time out
>
> it seemed safer at first if I
hu Sep 10 11:38:50 CES 2009
> Subject: [9fans] dial and time out
>
> Hello 9fans,
>
> I have a bunch of threads, simply scheduled with yield() at the moment
> (I'll use alt later on), and each of them is calling dial() at some
> point. I don't want the other threads to w
> it seemed safer at first if I didn't have to worry about the procs
> preempting each other (and appart from that dial() bottleneck, I don't
> need them to), that's why I started with threads. I was thinking of
> sticking to threads and not using procs until I really do need them. But
> yeah, no r
it seemed safer at first if I didn't have to worry about the procs
preempting each other (and appart from that dial() bottleneck, I don't
need them to), that's why I started with threads. I was thinking of
sticking to threads and not using procs until I really do need them. But
yeah, no real good r
> I have a bunch of threads, simply scheduled with yield() at the moment
> (I'll use alt later on), and each of them is calling dial() at some
> point. I don't want the other threads to wait for "too long" when one
> of them is blocked on a dial() that will eventually time out.
> So I was thinking
Hello 9fans,
I have a bunch of threads, simply scheduled with yield() at the moment
(I'll use alt later on), and each of them is calling dial() at some
point. I don't want the other threads to wait for "too long" when one
of them is blocked on a dial() that will eventually time out.
So I was thin
