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

[Jean-Michaël Celerier]

>  Add too many .qch files to a
collection and at some point the Assistant (or apps doing similar things)
will
crash

yeap, for me this makes QtCreator crash all the time on linux - fairly
frustrating, you're writing code, want to see the doc of some class, press
F1 and then boom ! byebye qtc


-------
Jean-Michaël Celerier
http://www.jcelerier.name


On Sat, Oct 13, 2018 at 10:15 AM René J. V. Bertin <rjvbertin at gmail.com>
wrote:

> 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.
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20181014/1ba85f2d/attachment.html>