Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
You didn't work on Netscape 4.x did you? :) What did you do when the pipe became full?
Kernel events without kevents
Posted Mar 15, 2007 11:05 UTC (Thu) by pphaneuf (guest, #23480)
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)
Posted Mar 15, 2007 12:50 UTC (Thu) by pphaneuf (guest, #23480)
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)
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)
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)
Posted Mar 15, 2007 16:38 UTC (Thu) by pphaneuf (guest, #23480)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds