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
