Positions forming in the Debian init system discussion

Posted Jan 2, 2014 1:05 UTC (Thu) by wahern (subscriber, #37304)
In reply to: Positions forming in the Debian init system discussion by Cyberax
Parent article: Positions forming in the Debian init system discussion

*BSD already has equivalents for epoll and signalfd. In fact, *BSDs signal events are infinitely more convenient. On Linux a signal can only be received by a _single_ listener. On *BSD the signal is delivered to all listeners.

Likewise, on Linux signalfd will not catch ignored or delivered signals (that is, signals with a handler). You have to block the signal in order to use signalfd to see it. This is not so on *BSD.

eventfd is nice, though. If you're using it as a true counting semaphore, there's no substitute. Most people usually use it in place of a signaling pipe, however, in which case it's trivial to just use a pipe.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 1:34 UTC (Thu) by wahern (subscriber, #37304) [Link]

Or if not a pipe, some kqueue implementations have a user event (e.g. EVFILT_USER on FreeBSD), or you can just install a 0 second timeout. That way you're only dealing with a single descriptor, just like eventfd.

Solaris, OTOH, has no signal listening primitive, which is really annoying. OTOH, it's O(1) polling primitive is always one-shot, which sounds less than optimal but is really very smart. They can optimize persistence behind the scenes while avoiding threading+event pitfalls that plague modern software.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 9:38 UTC (Thu) by smurf (subscriber, #17840) [Link] (4 responses)

So if you want to dispatch a single signal to multiple recipients in Linux, that's easy, just write ten lines of code to dispatch the signal information to the workers.

OTOH if you have a bundle of possible signal handlers in BSD (multiple worker threads for instance), that's easy too, just write a signal handler which triggers the next-available thread.

I cannot imagine a situation where sending a signal to both a traditional handler and signalfd would make sense. If warranted, the signalfd reader can call the traditional handler explicitly. But to have the kernel do that by default seems foolish to me.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 20:42 UTC (Thu) by wahern (subscriber, #37304) [Link]

Say you have a library (like my cqueues library) that provides a portable interface to non-blocking event management, including receiving signals. Say you have two separate tasks running inside the same process, mostly oblivious to each other (because they're black boxed, independent modules), and each wants to be signaled on SIGHUP so each can reset its internal configuration or state, but doesn't want to leak this abstraction to the hosting code.

On Linux you have to create a special-purposed centralized signal dispatcher in your library to do this. Not on BSD.

On Linux creating this centralized signal dispatcher forces you, as a library writer, to have to initialize and maintain a global state object. This is exceptionally ugly. I chose not to do that, because my library is meant to be embeddable (including trivially pluggable into any event loop) and guaranteed not to do crazy things behind the hosting application's back (that means no hidden mutexes, for example, which might complicate forking or create unnecessary dependencies).

So, I'm sorry, there's no excuse here. I understand why Linux did it--because it requires hacking up the signal dispatching code in the kernel to support multiple receivers. But *BSD put in the effort, and they have a better interface to show for it.

On the flip side, Linux has eventfd and *BSD doesn't. Linux has the better interface in this regard for pollable, counting semaphores. No excuses.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 23:38 UTC (Thu) by sionescu (subscriber, #59410) [Link] (2 responses)

Imagine two different pieces of code in the same process that spawned subprocesses and want to handle SIGCHLD but have no means of coöperating because they haven't been written with that concern in mind.

Positions forming in the Debian init system discussion

Posted Jan 3, 2014 21:57 UTC (Fri) by smurf (subscriber, #17840) [Link] (1 responses)

I'd assume that if one of the threads in question is in a syscall / blocking signals / whatever, the signal in question is consumed by the other one, leading to an interesting race condition.

In any case I consider a library's dependency on SIGCHLD delivery (or indeed the fact that it installs a SIGCHLD handler at all) to be a bug. There are more reliable methods to get notified when a process has gone away, e.g. when reading from its STDERR returns EOF.

Positions forming in the Debian init system discussion

Posted Jan 4, 2014 1:51 UTC (Sat) by wahern (subscriber, #37304) [Link]

What race condition? We're talking about the poor behavior of signalfd. This is the inconvenient behavior: if you create two separate signalfd descriptors, each listening for the same signal, only one of them will see it. With that kind of simple behavior, one could pretty much implement signalfd entirely in userspace, for all it's worth.

On BSD you could listen for SIGCHLD with kevent+EVFILT_SIGNAL on two seperate kqueue descriptors, reap with wait4 or waitpid, and there'd be no race whatsoever.