[9fans] Blocking reads on single-threaded Srv-based 9p server?

[9fans] Blocking reads on single-threaded Srv-based 9p server?

[Colin DeVilbiss]

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

Re: [9fans] Blocking reads on single-threaded Srv-based 9p server?

[Kris Maglione]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

On Thu, Apr 05, 2007 at 10:33:17PM -0500, Colin DeVilbiss wrote:
>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().

I'm not aware that it implies that, but I see no reason that you 
shouldn't do this in a single threaded server.

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

Yes, it sounds reasonable, it's very similar to what I do in wmii.

>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?

wmii (not part of plan9port) is single-threaded and Srv-based (though 
not lib9p based. The interface that it uses copies lib9p).

-- 
Kris Maglione

Despite the sign that says "wet paint",
please don't.

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [9fans] Blocking reads on single-threaded Srv-based 9p server?

[pedro henrique antunes de oliveira]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

"s there some reason that I shouldn't implement that in a single-threaded
server?"

you've asked that. i'm not an expert about concurrent programming, i've
never used threads, but here:  http://swtch.com/~rsc/thread/  (it's about
that subject)
if you read, you'll see that there that 'block' mechanisms are used to keep
the system synchronyzed, becuase using that block mechanisms keep the system
simple too.

in systens that you arent going to use concurrent programming, you can do
the synchronization in other ways, more simples, i think.

if i didnt understand the document wrong, what I've said make some sense..


i'm new to plan9 'world', and what i'm seeing is that concurrent programming
here is too much common, and you'll find a lot of specialist in the subject
here, and, probably get good help to your software. good luck.

[-- Attachment #2: Type: text/html, Size: 1019 bytes --]

Re: [9fans] Blocking reads on single-threaded Srv-based 9p server?

[pedro henrique antunes de oliveira]

[-- Attachment #1: Type: text/plain, Size: 141 bytes --]

" if i didnt understand the document wrong, what I've said make some
sense.."

i mean

"if i did understand the...."
sorry the flood.

[-- Attachment #2: Type: text/html, Size: 190 bytes --]

Re: [9fans] Blocking reads on single-threaded Srv-based 9p server?

[erik quanstrom]

> "s there some reason that I shouldn't implement that in a single-threaded
> server?"

i don't think there's a general answer for this.  the important questions
are probablly
1)  given how long my program may block gathering a response, is it a
problem that all clients block during this time.
2)  will i drop events if i'm busy talking to a client?

if the answer is "no" to both, why bother with more than one thread?

> 
> you've asked that. i'm not an expert about concurrent programming, i've
> never used threads, but here:  http://swtch.com/~rsc/thread/  (it's about
> that subject)
> if you read, you'll see that there that 'block' mechanisms are used to keep
> the system synchronyzed, becuase using that block mechanisms keep the system
> simple too.
> 
> in systens that you arent going to use concurrent programming, you can do
> the synchronization in other ways, more simples, i think.

not all threaded programs are created equal.

csp is not too bad.  locking is subtile and quick to anger.

- erik

Re: [9fans] Blocking reads on single-threaded Srv-based 9p server?

[Russ Cox]

On 4/5/07, Colin DeVilbiss <cdevilbiss@gmail.com> 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

Re: [9fans] Blocking reads on single-threaded Srv-based 9p server?

[Skip Tavakkolian]

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

sometimes the resource that the fs is managing dictates the
behavior; e.g. /n/sources/contrib/fst/dcfs.tgz