On 4/5/07, Colin DeVilbiss <[EMAIL PROTECTED]> wrote:
I'm implementing a 9p server using plan9port.
I'd like one of my files to have "blocking read" or "blocking write"
behavior: any such call should block until a write occurs on some
other (non-blocking) file in the same server.
This is perfectly fine to do in a single-threaded server.
You need to implement flush to make sure that clients
don't get hung up indefinitely.
Is there some reason that I shouldn't implement that in a
single-threaded server? The 9p(3) plan9ports manpage suggests that
only multi-threaded servers should "block" requests by not
respond()ing to them before returning from the associated service
routine, and that only multi-threaded servers would need to implement
flush().
The text is admittedly misleading.
I removed mention of single vs multi-threaded programs.
The real issue is whether requests are always replied to
before returning from the Srv function. If so, no need
for flush. If not (which is okay), you need to provide a flush.
My plan:
In my Srv's read() (or write()) routine, if a Req comes in for
that file and I decide that it should block, I save it off somewhere
and don't respond() to it.
In my write() routine, if a "should unblock any waiters" event
occurs, go find all of the associated "saved" Req's and respond() to
them all.
Implement a flush() routine that "un-saves" the oldreq and
responds with "interrupted" (per the manpage).
This is perfectly fine to do in a single-threaded program
and is very common. Aux/consolefs does it (without lib9p),
and the p9p auth/factotum/log.c implements a one-sided
variant of it for reading from the event log.
As a side note, I see that none of the 9p filesystems that are
currently packaged in plan9port are both single-threaded and
Srv-based. Is there some reason I don't want to do that here?
P9p's lib9p requires libthread in order to create new processes.
(If someone ever ports p9p to Windows, they'll be happy that
libthread's interface is the only one used to start new programs
instead of widespread use of fork+exec.)
That doesn't mean your program has to be multithreaded.
You can write single-threaded libthread programs.
Russ
