Re: [9front] discussion: general fix for 9p status files which don't accept multiple readers

Re: [9front] discussion: general fix for 9p status files which don't accept multiple readers

[vp]

Another option is running mycroftiv's hubfs
and a bunch of cats for reading and writing
the files in question.
The server:
	hubfs -s multipipe
	mount -c /srv/multipipe /mnt/p
	cat /dev/kbd > /mnt/p/kbd &
The client(s):
	mount -c /srv/multipipe /mnt/p
	cat /mnt/p/kbd
Either the server or the clients could bind the
hub files or a directory wherever they please.
Note that you can create directory hierarchies
in hubfs just fine.

One *big* problem is that hubfs can, and will,
coalesce the messages at its leisure, masking
the write boundary behaviour that many
existing readers of stuff like /dev/kbd rely on.

- kvik

Re: [9front] discussion: general fix for 9p status files which don't accept multiple readers

[Silas McCroskey]

That's more or less what I'm suggesting, modulo a different multipipe
and an easier setup (bind over and read from could be default here, as
it is with mixfs). The existing multipipe.c does what hubfs does, but
only serves a single multipipe and responds to all readers once for
each write. It also doesn't save messages that all existing readers
have already read (so none at all, if there aren't currently any
readers), which I think is more appropriate for this use case (mod the
"respond with the current state on first read" part). hubfs is great,
but it handles a bunch of extra stuff that at best isn't necessary
here and at worst causes problems like the one you mentioned re:
coalescing.

- sam-d

On Wed, May 22, 2019 at 6:32 AM <vp@kvik.link> wrote:
>
> Another option is running mycroftiv's hubfs
> and a bunch of cats for reading and writing
> the files in question.
> The server:
>         hubfs -s multipipe
>         mount -c /srv/multipipe /mnt/p
>         cat /dev/kbd > /mnt/p/kbd &
> The client(s):
>         mount -c /srv/multipipe /mnt/p
>         cat /mnt/p/kbd
> Either the server or the clients could bind the
> hub files or a directory wherever they please.
> Note that you can create directory hierarchies
> in hubfs just fine.
>
> One *big* problem is that hubfs can, and will,
> coalesce the messages at its leisure, masking
> the write boundary behaviour that many
> existing readers of stuff like /dev/kbd rely on.
>
> - kvik

Re: [9front] discussion: general fix for 9p status files which don't accept multiple readers

[hiro]

i had the same dilemma and concluded like sam-d.
hubfs uses the same building blocks this might need, so one can learn
how to do it from hubfs, but as it is right now it wouldn't be so
suitable.

Re: [9front] discussion: general fix for 9p status files which don't accept multiple readers

[hiro]

what i don't get: rio, and what edge cases you need to solve there...
rio serves all the things commonly needed by multiple readers in the
expected way, or?

Re: [9front] discussion: general fix for 9p status files which don't accept multiple readers

[Silas McCroskey]

My mistake, I meant /dev/wctl rather than /dev/window, but here's what
I'm referring to:
https://code.9front.org/hg/plan9front/file/523d2d3e473f/sys/src/cmd/rio/xfid.c#l293

cinap challenged me to solve this ages ago when I was discussing some
window management scripts with him, and I've been overanalyzing the
solution ever since :)

- sam-d

On Wed, May 22, 2019 at 3:55 AM hiro <23hiro@gmail.com> wrote:
>
> what i don't get: rio, and what edge cases you need to solve there...
> rio serves all the things commonly needed by multiple readers in the
> expected way, or?