Kernel events without kevents
Kernel events without kevents
Posted Mar 15, 2007 8:17 UTC (Thu) by Ross (guest, #4065)In reply to: Kernel events without kevents by felixfix
Parent article: Kernel events without kevents
You didn't work on Netscape 4.x did you? :) What did you do when the pipe became full?
Posted Mar 15, 2007 11:05 UTC (Thu)
by pphaneuf (guest, #23480)
[Link] (2 responses)
Was that a trick question, because if so, I don't get it.
Posted Mar 15, 2007 12:43 UTC (Thu)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Mar 15, 2007 12:50 UTC (Thu)
by pphaneuf (guest, #23480)
[Link]
The way Netscape 4 would wedge itself the most often for me (because I would often strace it when it did, since I was working on a big event-driven single-threaded program as well, and I'm curious to boot!) was to be reading the same file descriptor over and over, getting zero, and not getting the hint, for some reason.
I suspect there was a bit of code that wanted to do just the ONE synchronous thing, and of course, it screwed up and blocked the whole program. Tsk tsk tsk...
Posted Mar 15, 2007 15:28 UTC (Thu)
by felixfix (subscriber, #242)
[Link] (3 responses)
The point is to not have multiple bytes which might not be written contiguously.
Posted Mar 15, 2007 16:04 UTC (Thu)
by pphaneuf (guest, #23480)
[Link] (2 responses)
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. ;-)
Posted Mar 15, 2007 16:17 UTC (Thu)
by felixfix (subscriber, #242)
[Link] (1 responses)
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.
Netscape 4.x was a single-threaded, event-driven program, so you do like every other file descriptor, set it non-blocking, and ignore EAGAIN.Kernel events without kevents
Netscape 4 had a habit of going into interminable stalls :)Kernel events without kevents
Ah, there are many ways in which to wedge one-self, but thankfully, I think the simplest ones were indeed avoided. ;-)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.Kernel events without kevents
Kernel events without kevents
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
Kernel events without kevents