Kernel events without kevents [LWN.net]

Kernel events without kevents

Posted Mar 15, 2007 15:28 UTC (Thu) by felixfix (subscriber, #242)
In reply to: Kernel events without kevents by Ross
Parent article: Kernel events without kevents

You have a main loop somewhere using select to read various file descriptors. One of them is the single byte signal pipe. You read that single byte.

The point is to not have multiple bytes which might not be written contiguously.

(Log in to post comments)

Kernel events without kevents

Posted Mar 15, 2007 16:04 UTC (Thu) by pphaneuf (guest, #23480) [Link]

It behaves just like a real signal. You get at least one, but it's possible that you lose some due to overflow (the signal handler got EAGAIN and ignores it, giving similar behaviour). The reading end should read until EAGAIN, of course, to drain the pipe, before handling the signal (so that if another signal comes in, it is not missed). Of course, I also use something like a 1K buffer on the stack to "eat" the bytes, I don't read a single byte at a time.

If you really want to avoid this, you can have a bool set aside that you test before writing the byte, set to true when you did, and so on, but I prefer to let the kernel do all the book-keeping for me, I have plenty of other opportunities to screw up.

On a pipe, everything is contiguous. Unless you find a way to seek. ;-)

Kernel events without kevents

Posted Mar 15, 2007 16:17 UTC (Thu) by felixfix (subscriber, #242) [Link]

Multiple writers to one pipe can easily interleave. It's been a while now, but there is that message pipe, is it the ATT substitute? which only writes complete messages atomically or returns an error. But regular pipes have no guarantees, just like writing to any file. If your data crosses a block boundary, you have no guarantees, and maybe not even if you stay within block boundaries.

Kernel events without kevents

Posted Mar 15, 2007 16:38 UTC (Thu) by pphaneuf (guest, #23480) [Link]

Well, since I don't even look at the value that I read, it doesn't matter much, doesn't it?

Depending on environmental constraints, I either use a pipe per signal, or the pipe is only to "wake up" the select() and I check some volatile bools that the signal handlers set to know which one it was.

Furthermore, since my "messages" are a single byte (I usually use 42 as a value), and that's the granularity of a pipe, they'd still be atomic. That's if I cared about their value, of course.