> 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 <[email protected]> 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/interest >
_______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
