Channel sessions

[Carl Fredrik Hammar]

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

[task #7096] glibc 2.6 support

[Samuel Thibault]

URL:
  

 Summary: glibc 2.6 support
 Project: The GNU Hurd
Submitted by: sthibaul
Submitted on: jeudi 19.07.2007 à 22:34
Category: None
 Should Start On: jeudi 19.07.2007 à 00:00
   Should be Finished on: jeudi 19.07.2007 à 00:00
Priority: 5 - Normal
  Status: None
 Privacy: Public
Percent Complete: 0%
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None
  Effort: 0.00
Wiki-like text discussion box: 

___

Details:

Here is a tracker for non-trivial issues on glibc 2.6

sysdeps/i386/i486/bits/atomic.h uses the multiple_threads TLS field for
knowing whether to put a lock prefix before atomic operations or not. Since
we start a signal thread in each process anyway, this is probably useless and
we should rather always put the lock prefix? (hence have our own copy of
atomic.h)





___

Reply to this item at:

  

___
  Message posté via/par Savannah
  http://savannah.gnu.org/



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

[bug #17644] glibc: support for TLS

[Samuel Thibault]

Follow-up Comment #15, bug #17644 (project hurd):

Here are updated patches. I don't have any issue any more, other people don't
seem to have either.


(file #13404, file #13405, file #13406)
___

Additional Item Attachment:



___

Reply to this item at:

  

___
  Message posté via/par Savannah
  http://savannah.gnu.org/



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion '! __spin_lock_locked (&ss->critical_section_lock)' failed

[Thomas Schwinge]

Hello!

On Sun, Aug 06, 2006 at 01:57:34PM -0700, Roland McGrath wrote:
> > Samuel Thibault, le Sat 05 Aug 2006 02:45:34 +0200, a écrit :
> > > Samuel Thibault, le Sat 05 Aug 2006 02:27:35 +0200, a écrit :
> > > >   assert (! __spin_lock_locked (&ss->critical_section_lock));
> > > >   __spin_lock (&ss->critical_section_lock);

I've now also hit that one (for the first time, as far as I can tell).

> > > > Why should one check that a spinlock is free before taking it?? Here the
> > > > purpose is to cancel _another_ thread, so it _can_ happen that the lock
> > > > be taken any time...
> > > > 
> > > > Shouldn't at least these assertion just be dropped?
> > > 
> > > Maybe not the ones from other files, which are not trivial, but at least
> > > this one (thread-cancel), which was reported to actually happen, and
> > > which to my mind is really arguable.
> > 
> > I got it again this afternoon...
> 
> Please show the backtraces of relevant threads.

Given that I got it on the root file system server and we (so far) have
no measures of reproducing it reliably, that'd be a bit difficult.


Regards,
 Thomas


signature.asc
Description: Digital signature
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd