Re: Realtime safe signalling?
- From: Igor Gorbounov <igorbounov topazelectro ru>
- To: Jan Hudec <bulb ucw cz>
- Cc: gtkmm-list gnome org, Paul Davis <paul linuxaudiosystems com>
- Subject: Re: Realtime safe signalling?
- Date: Mon, 21 Feb 2005 10:48:07 +0300
Jan Hudec wrote:
Do you mean this quote from
"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." ?
On Tue, Feb 01, 2005 at 17:30:51 -0500, Paul Davis wrote:
no. none of these mechanisms are safe.
you need to to use some kernel facility (FIFOs are my favorite) to do
And what do you think Glib::Dispatcher::emit() is using?? Right, FIFOs.
Be sure not to share one dispatcher between several threads though as it
does some locking.
no locking is acceptable at all for RT usage. My implementation of the
same idea stuffs Slots into a lock-free FIFO, and then writes a single
bytes to the FIFO to wake up the GUI. If you lock, its not RT-safe.
Yes. Sure. Glib::Dispatcher is no good for RT.
But can FIFO, created wth the use of mkfifo, be of a proper use for RT
signals? There is a special file created in
a filesystem - is it good?
] [Thread Prev