Threads are great for preventing race conditions. I agree.
Many Plan 9 applications (ria, acme, etc.) use a central proc with lots of
threads doing the real work of manipulating the state of the application.
No locks are required, because the threads explicitly yield by doing
channel io or calling yield().
IO is done by single-threaded procs, almost one per file descriptor.
These IO threads typically run on the lines of:
void
ioproc(void *a)
{
for(;;){
read(fd, ...)
send(channel, ...)
}
}
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 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 reason not to switch to procs if that's the best way
> to go in that case.
>
> Mathieu.
>
>
> — 2/
