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
