[9fans] Help on /srv, named pipes

[9fans] Help on /srv, named pipes

[Sascha Retzki]

Hi,

I am playing arround with irc7, a multichannel irc-client. There is irc, which uses /srv (a named pipe to ircsrv) for outgoing things (commands to be send to the irc-server), but a file in /tmp to recieve data from the irc-server. (One (may) use irc to just read/write to one target/victim (irc channel or person), so I just open two-three win(1)s in acme and start ircs' for each channel I want to be in).

I don't like the incoming data to be in /tmp, for example it behaves like a logfile, it spams my harddisk, etc. Most importantly, I did not get why there is a named pipe waiting for clients in /srv, but a file in /tmp is used.

So I changed irc7/irc.c to read/write all traffic via /srv/glendairc and made ircsrv.c write to /srv/glendairc instead of /tmp/whatnot. Piece of cake.


Reading pipe(3):
If there are multiple writers, each write is guaranteed to
be available in a contiguous piece at the other end of the
pipe.  If there are multiple readers, each read will return
data from only one write.

I read 'from only one write' as 'multiple "clients" may open and use /srv/glendairc, they all will get all data (ordered)' - however that is not the case. Depending on which one of the clients is currently reading (or so it seems), it is the only recipient. I have got a question at this point: Did I misget that concept? Is that intentioned behaviour (why?)?
(In case it matters, libbio is used to recieve the data from /tmp^W/srv/glendairc )



I put the current source-code at sources:
9fs sources
/n/sources/contrib/sascharetzki/src/irc7.2-srv-only.tgz 


In case I do get all the concepts right, and I just did not write correct code, I will go and read my code again. Examples (greping for /srv in /sys/src/cmd/*.c isn't that much fun after all ;-/ )?


Thanks for your time,


Sascha

Re: [9fans] Help on /srv, named pipes

[Russ Cox]

> If there are multiple writers, each write is guaranteed to
> be available in a contiguous piece at the other end of the
> pipe.  If there are multiple readers, each read will return
> data from only one write.

This says that if reading from a pipe preserves the
message sizes written to the pipe, and that each read
gets an entire message (when possible) but not
a message and a half.

Pipes do not deliver writes to all readers.
(Nor do network connections, nor Unix pipes.)
If you want to do that you need an arbitrarily
large buffer to accomodate slow readers.
Something like... a file in /tmp.

Russ

Re: [9fans] Help on /srv, named pipes

[Skip Tavakkolian]

> So I changed irc7/irc.c to read/write all traffic via /srv/glendairc and made ircsrv.c write to /srv/glendairc instead of /tmp/whatnot. Piece of cake.

except only one pending read of /srv/glendairc
will succeed.  have you thought about putting an
fs in front of it?  each client gets its own copy of
what comes from the network.

(user1) <-> fs/0/data \
(user2) <-> fs/1/data  } <=chan(irc)=> proc(ircsrv/mux)
(user3) <-> fs/2/data /

i think there's an example in nemo's intro book.