[Interest] proper (silent) exit in response to SIGHUP?
thiago.macieira at intel.com
Fri Oct 12 22:54:04 CEST 2018
On Friday, 12 October 2018 11:37:52 PDT René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > They're not. They're just the first link I found when googling for "signal
> > safe". The official list comes from POSIX.
> I did some homework of my own. Turns out these signals are also known as
> "ANSI signals" or "standard C signals" and are actually part of standard
> (at least some, including SIGINT and SIGTERM, but not SIGHUP). So they do
> exist on MS Windows. With very similar limitations, even.
Yes, but no one uses them on Windows. In the UNIX world, they're used and part
of system administration.
C also leaves unspecified how signal delivery interacts with multithreading.
POSIX does clarify that. But Windows isn't a POSIX system, so the rules don't
> > QFSW on BSD uses kqueue, so one fd per QFSW.
> Indeed, so in something like an IDE that wants to monitor an entire source
> tree for changes you quickly run out of available file descriptors (was the
> case too with Qt4 on Mac). That can be catastrophic (QThreadPipe will start
> failing). That's the reason I was hoping to be clever and use something
> other than a set of 2 file descriptors for an anonymous pipe.
Get your vendor to provide an object with a single file descriptor then. Linux
did that on version 2.6.23, 11 years ago. eventfd are cheaper than pipes on
the kernel side too, as they only consume 8 bytes of storage (plus overhead),
instead of a 128 kB buffer.
Another interesting tidbit is that Linux hasn't used 256 fds per process since
the 2.0.x kernel series. That's over 20 years ago. And even in the 2.0 series
it could be increased if you recompiled the kernel, unlike in the 1.2 series.
And here's why I know this: because when I started learning about Linux,
*this* was the reason why the DALNet IRC servers were switching from Linux to
FreeBSD: back then, FreeBSD supported more than 256 file descriptors per
process. So I know for a fact that FreeBSD (and thus Darwin today) do support
more. It may not be the default, so just adjust it.
> > Trivia: FreeBSD has eventfd, but it's not available for FreeBSD-native
> > applications. It's only available for Linux ones.
> Hmmm, I thought epoll-shim provided an implementation?
I meant a native implementation of eventfd, with the same semantics. But
there's no system call to access them from a FreeBSD-native process. You can
only get to it by way of the Linux emulation.
> > If you meant "emit a signal", then it's one of the two:
> Yes, a queued connection, evidently. It's not immediately evident from the
> documentation that this allocates memory (if you don't already know it).
Not from the documentation, but it's logical. It's a *queued* connection, so
something needs to be added to a queue. It's that which allocates memory.
There's no allocation-free queue data structure, at least not one that can
handle up to thousands of events stored and queued. Even if we made it
allocation-free for the typical cases, your code would have to contend with
the untypical case and would therefore be unsafe.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Interest