On Mon, Feb 21, 2005 at 11:26:16 +0300, Igor Gorbounov wrote: > Jan Hudec wrote: > > >On Mon, Feb 21, 2005 at 10:48:07 +0300, Igor Gorbounov wrote: > > > > > >>Do you mean this quote from > >>http://www.gtkmm.org/docs/glibmm-2.4/docs/reference/html/classGlib_1_1Dispatcher.html: > >>"After instantiation, Glib::Dispatcher will never lock any mutexes on > >>its own. The interaction with the GLib main loop might involve locking > >>on the /receiver/ side. The /sender/ side, however, is guaranteed not to > >>lock, except for internal locking in the |write()| system call." ? > >[...] The writer of the manual could not guarantee how will write(2) behave, since the code is system-independent. Linux does protect pipe with a semaphore. On single-CPU, it can never be waited for unless the buffer is full. On SMP it can and since it is a semaphore, it will cause schedule() there. > And what is it about: "...except for internal locking in the |write()| > system call." ? Which locking is meant here? > > >The fact that it's in a filesystem is only important when opening it. > >Once it is open, it's just a fifo. However, it might still block if the > >reader is too slow and the internal buffer fills up. So it's ok for soft > >realtime (where it's acceptable to block once in a year) but not hard > >realtime. > > So if I put in that fifo only one byte - this buffer overfilling would > never be possible? And it would be > very reliable? Hm. Except for the in-kernel locking. I don't realy trust it now, but I have not looked too carefuly either. See http://lxr.linux.no/source/fs/pipe.c ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bulb ucw cz>
Attachment:
signature.asc
Description: Digital signature