Subj : Re: Threads and signals To : comp.programming.threads From : steve Date : Mon Jan 24 2005 07:44 pm In article <87sm54jeye.fsf@qrnik.zagroda>, Marcin 'Qrczak' Kowalczyk wrote: >When a signal is sent to a process by kill(), or is generated by >setitimer(), which thread handles it? Whatever thread is most inconvenient. Per POSIX, any thread in the process (that has the signal unmasked) can receive the signal. It's not unusual for implementors to be lazy, however, and deliver it to the thread that ran main(), if that thread is still around. Older Linux distributions, without NPTL, often did this, and other wrong things related to signals and threads. >sigprocmask must be used only in single-threaded programs, right? >But pthread_sigmask brings a dependency on pthreads. Does it mean >that it's impossible to write code which blocks signals temporarily, >doesn't create a dependency on pthreads, but if it's linked with >another library which uses pthreads then they still work? If you don't create threads, use sigprocmask. If one of the libraries you're calling creates threads and expects those threads to do useful things with respect to signals, your sigprocmask should still work OK. At least, that's my opinion. Implementation bugs are a different issue... -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... .