Opened 9 years ago

Last modified 7 years ago

#699 new defect

thread creation foils libraries that rely on blocking signals

Reported by: fare Owned by:
Priority: normal Milestone:
Component: Runtime (threads, GC) Version: trunk
Keywords: ITA Cc:

Description

When creating a thread, function new_tcr is called, which uses an empty sigset to initialize the pthread_sigmask.

This is incorrect, and causes programs using signalfd to lose signals to whichever default or non-default signal handler may be installed.

One correct behavior would be to maintain a global default sigmask which may be non-empty, initialized when Lisp is still running in single-threaded mode, and carefully updated by modifying all threads to also block or unblock the newly handled signal.

Another alternative correct behavior would be that all threads but a special one would block all signals but those they specifically want to handle.

This is all the more annoying since even if I run single-threaded-ccl, such library functions as run-program create threads. I'm losing SIGCHLD events that way.

Change History (3)

comment:1 Changed 9 years ago by rme

I've considered changing run-program to use posix_spawn(2) (ref ticket:687), if that would help your situation at all.

I have to admit that I'm a little confused about what you want to do. Could you provide a concrete example?

comment:2 Changed 9 years ago by fare

The problem is NOT fork+exec vs posix_spawn, but the running of either inside a thread. That's evil because CCL threads reset the pthread_sigmask on thread creation (which they probably shouldn't), and the thread then catches the signal in its handler, which can't be processed through signalfd anymore. That said, whichever you call, it's nice indeed if the signals are reset to some default as part of spawning a child process.

Concrete example: a large application that has an event-loop in which signalfd is used to monitor SIGCHLD, and that once in a while uses run-program. The moment that the thread is created, it handles the signal, and then the event-loop never gets notified that a signal was received.

comment:3 Changed 7 years ago by gz

  • Keywords ITA added
Note: See TracTickets for help on using tickets.