* Marc Lehmann <[email protected]> [12/04/28 21:48]: > > Unless I block signals in all threads but the main, the signal > > sent to a process can be delivered to any thread, and thus libev > > won't see it. > If this is the case, then this is another issue, independent of > libev. Libev does not care which thread handles the signal, it only > cares about not receiving a signal while it manipulates it's signal data > structures.
I don't think it's going to be the case if signalfd is used. But generally, if I remember my Butenhof (*) correctly, that's what can happen according to SUSv2/POSIX. > > I was wondering what would be a canonical way to do it? > Well, your problem seems to come from another component, not libev. Libev > is fine with either way. > > > A simple approach is to temporarily block signals by calling > > pthread_sigmask(), then call pthread_create(), make sure the created > > thread inherits the signal mask, and then unblock signals > > again and let libev handle them. > > Blocking all signals in threads that are normally not interested in > handling them is good programming practise, and the way you describe is > the canonical way to do that (i wish glib would do that :). > > It's not required for libev, though - libev doesn't know anything about > threads, and does not care about which thread handles the signal. Thanks! -- http://tarantool.org - an efficient, extensible in-memory data store _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
