Hello! I've thinking about use-cases for libchannel and started work on channelio for the last few days and it got me thinking about sessions.
I found that I've been assuming that character devices are session-less, mostly because they, unlike stores, are not seekable. Now I'm not so sure that is the case. 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! The reason for this is that channelio, upon a io_read call from the recorder, fills it's output buffer with input from the sound driver and copies over the requested amount to the client supplied buffer and discards it from the output buffer. Later the broadcaster does the same and receives the audio that follows the audio supplied to the recorder. The right thing to do is to wait until all clients have read the buffer until its contents are discarded, blocking clients that have already read it. Here we also need to impose a time-out, when processes that can't keep up looses data or gets an error. However the former is also a valid behavior for some character-device translators. Such as /dev/random, where we don't want to all clients to receive the same random data. This is all made worse by the fact that channels can be copied to other processes so that they can do io with it directly, which means session-state must be shared by all processes holding the channel. It seems like this will turn out to be a mess. I want to have a sanity check before I dig deeper. Does all this make sense to you guys or am I thinking to much? Also how are sessions like above handled by kernel devices? Are they handled at all? Can someone point me to a good example? Regards, Fredrik _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
