On Tue, Feb 01, 2005 at 17:30:51 -0500, Paul Davis wrote: > >> no. none of these mechanisms are safe. > >>=20 > >> 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. > >> this, and even that is not strictly realtime safe (its better if the > >> FIFOs are in a tmpfs file system, for example). > > > >It does not matter in what filesystem (if any -- see pipe(2)) the fifo > >is in, because the inode is always in "pipefs". What does matter is to > >make that fifo non-blocking (see fcntl(2)). > > sorry, i was confusing RT-safe IPC with RT-safe intra-process > communication. you're right, if you use pipe(2), the filesystem is > irrelevant. NO! The filesystem is *ALWAYS* irrelevant, because the file_operations are always the same. It does *not* use the filesystem to back any buffers or anything. ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bulb ucw cz>
Attachment:
signature.asc
Description: Digital signature