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

[René J. V. Bertin]

Thiago Macieira wrote:

> Yes, but no one uses them on Windows. In the UNIX world, they're used and part
> of system administration.

So you're saying there's no point in trying to find an MSWin alternative for 
pipe() because chances are too slim that the application would ever receive a 
signal? I forgot to mention that aspect before: pipe() not being cross-platform 
was another reason I have been looking for alternative approaches.

If so, there's the alternative of using a semaphore (not a QSemaphore; 
sem_post() is safe according to the POSIX docs) though that would probably 
require a separate thread and a trick to rearm the mechanism. A Qt wrapper 
around "native" semaphores could have made this easier.

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

Apparently you can't use SIGINT the same way as elsewhere because it makes a 
single-threaded application multi-threaded. I haven't done any windev since XP 
but I read that particular point as moot for multi-threaded apps.

> Get your vendor to provide an object with a single file descriptor then.

Sorry, vendor? Object?

> 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

Well, this is not about which OS is better than which other OS :)

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

The QFSW documentation still mentions the 256 fd limit explicitly.

Darwin is *not* FreeBSD (can't remember which other flavour) though apparently it 
was "synchronised with FreeBSD 5" for the release of 10.3.0; and of course it 
has a completely different kernel beast.
There must still be a QTBUG somewhere about the QFSW saturation in Qt4, and then 
there's an open issue about QtHelp which suffers from the same open file 
descriptor limit on Mac (and presumably *BSD). Add too many .qch files to a 
collection and at some point the Assistant (or apps doing similar things) will 
crash. I don't have access to my Mac right now so I can't confirm whether I maxed 
out the open fd limit or whether the system call is being ignored.



> Not from the documentation, but it's logical.

That's what I meant, it's logical with hindsight.

> allocation-free for the typical cases, your code would have to contend with
> the untypical case and would therefore be unsafe.

Would it? A signal handler can be unique and work with structures that have been 
preallocated. Typically you'd only need to update the signal number which 
doesn't require allocating anything.

I was halfway through a PoC implementation using a pre-allocated custom QEvent 
when I realised that QCoreApplication::sendEvent() is apparently synchronous so 
I'd need QCoreApplication::postEvent(). And that one does all kind of unsafe 
things. Transferring ownership of the QEvent wouldn't be a problem (just 
allocate a new one in the actual signal handler, if needed) but postEvent() also 
locks a mutex.

R.