[Interest] proper (silent) exit in response to SIGHUP?

[Thiago Macieira]

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 
applyt hrere.

> > 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