On 4/11/07, Charles Forsyth <[EMAIL PROTECTED]> wrote:
> Tread won't hurt very much. If you really care about minimizing
> the number of requests, you'd do better to have a single "events"
> file that got opened once and then polled (with blocking reads)
> to get information out of the device.
yes. we do that often; it works well. think of it as `publish/subscribe'
for the 21st century: instead of lots of peculiar new APIs and Pattern Names,
you open a file, and if needed write a subscription description; and read from
it.
the server knows.
plus, if you desperately need EOD, and it's your server, and only your
client, then put an EOD indicator in the data. I.e., there is a
claimed need to avoid the second tread for some reason. This need
stands outside what 9p does, and this 'second tread avoidance' is not
needed by any other 9p server or client, save for your client and your
server. So make every first byte of the packet sent by the server be
metadata providing additional information about the data in the
packet. You can use that first byte to be your EOD.
yeah, yeah, it's gross, but I've seen this sort of thing done where
"it really matters". The point is that there is nothing about 9p
clients and servers that rules this metadata out, and the fact that
the server is a program, written by you, makes this metadata very easy
to add in.
thanks
ron