From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Fri,  6 Apr 2007 02:30:50 -0400
From: Kris Maglione <bsdaemon@comcast.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Blocking reads on single-threaded Srv-based 9p server?
Message-ID: <20070406063050.GA27497@kris.home>
References: <6ec892cd0704052033r3ae400e2o54bfdf447da9d994@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6"
Content-Disposition: inline
In-Reply-To: <6ec892cd0704052033r3ae400e2o54bfdf447da9d994@mail.gmail.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
Topicbox-Message-UUID: 3ece294e-ead2-11e9-9d60-3106f5b1d025


--y0ulUmNC+osPPQO6
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=20
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=20
not lib9p based. The interface that it uses copies lib9p).

--=20
Kris Maglione

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

--y0ulUmNC+osPPQO6
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.2 (FreeBSD)

iD8DBQFGFekaseQZD8Aui4wRAqJyAKCF02BgAhJKpOai7Flt3BmqfiP8WwCfYZjX
WsO2WI3LH6TH8KGHtcQHXhk=
=GKRR
-----END PGP SIGNATURE-----

--y0ulUmNC+osPPQO6--