On Tue, Jan 22, 2008 at 08:51:55AM +0100, Ron Arts wrote: <snip> > Oops, I'm sorry, I did not make myself clear, while writing the > email I edited it a lot, and forgot to mention that indeed I > ignore SIGPIPE in my initialisation code: > <snip> > > But my program is still being killed with SIGPIPE occasionally. > I am using threads, and I presume sometimes one of the other threads > receives the SIGPIPE signal instead of the main thread, and I > *think* that in such a case my program exits. > > But what I meant to ask was: isn't libevent supposed (since 1.3) to handle > multithreading and ensure that only one thread receives the signal?
Neither libevent nor anything else can specify that any particular thread receive a signal. All that can be done is to block a signal in all threads except for one, which gives the same effect in a round-about manner. Since libevent doesn't create the threads, it can't block them like this. And, in any event, it would be evil for libevent to fiddle with signals this way behind a process' back. I wouldn't want libevent to preemptively block all signals from event_init(). > Or should I specifically add code at the beginning of each thread > to ignore SIGPIPE? Signal handlers and masks are inherited across fork() and pthread_create(). And masks are inherited across exec(), too, I think. You could add code to each thread to do this. Of course, there are race conditions. Imagine if a signal is raised after a thread starts but before it can block the signal. This is especially troublesome if you dynamically create threads. With SIGPIPE the answer is simple, though. Block the signal from the main thread before creating any other threads. All threads will inherit the block, and SIGPIPE can never squeeze through. But, by block I mean actually using sigaction(2) (see the code I posted earlier), not by installing a libevent handler. Installing a SIGPIPE handler through libevent is pointless and a waste of CPU, and of course it doesn't do what you want anyway. Signals are probably the most complex and difficult to understand concept in Unix, and understanding how to safely use them is even more difficult. I suggest you find a copy of Richard Stevens' Advanced Programming in the UNIX Environment. If Knuth and Stevens have (had) one thing in common, it's that no engineer would ever question why you one of their books sat on your book shelf. _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
