From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <6ec892cd0704052033r3ae400e2o54bfdf447da9d994@mail.gmail.com>
Date: Thu,  5 Apr 2007 22:33:17 -0500
From: "Colin DeVilbiss" <cdevilbiss@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: [9fans] Blocking reads on single-threaded Srv-based 9p server?
Topicbox-Message-UUID: 3eca56ac-ead2-11e9-9d60-3106f5b1d025

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.

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().

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).

Does that sound viable, or is there some machinery inside Srv that I
would run afoul of by doing that?

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?

Thanks.

Colin DeVilbiss