Re: Channel sessions

[Carl Fredrik Hammar]

<olafBuddenhagen@gmx.net> writes:
> Hi,
>
> On Thu, Jul 19, 2007 at 09:35:01PM +0200, Carl Fredrik Hammar wrote:
>
>> Suppose we want to record some audio which we may read from
>> /dev/sound/audio, which is a channelio translator.  Additionaly we
>> want to broadcast the audio onto our internet radio station.  These
>> tasks are handled by seperate processes which both need to read from
>> /dev/sound/audio.  However we will find that the audio is choppy in
>> both the recording and the broadcast!
> [...]
>> Also how are sessions like above handled by kernel devices?
>
> Most kernel devices allow only exclusive access. On Linux for example,
> only one client can open /dev/dsp at the same time.

Ok, thanks for the info!

> Splitting the input like you described, is magic that normally would
> require a special program. On the Hurd, we'd want a translator for this
> of course -- i.e. you probably have to consider it as one possible use
> for channelio. However, you do *not* need to assume that every single
> channelio module has to handle it I'd say, but only one specially for
> this purpose.
>
> -antrik-

Having special channel classes (or perhaps some other type of modules)
for it seems like the right way to go.  But the problem that these
channels can live in several translators remain.

I can think of two solutions atm.

1) The channel shares some memory with it's copies in other channels.

This is a bit ugly, but acceptable if only a few specialized channels
does it.

2) No copies are made, instead a single translator handles all the
file-system nodes that are connected this way.

The major problem with this is that it can't cooperate with other
channel translator implementations or other programs that might be
``channel aware''.

I'm currently leaning toward (1), since it's the least drastic change.

What is the hurdish way to do shared memory?  Are there more hurdish
alternatives to share state between processes?

Regards,
  Fredrik