On Monday, 15 October 2018 06:34:55 PDT René J. V. Bertin wrote: > Thiago Macieira wrote: > > You were complaining that pipes are too costly. Ok, so get your OS vendor > > to create an equivalent to Linux's eventfd() > > Sure. Dear Apple (FreeBSD), please implement eventfd() (and a bunch of other > Linux features because they make Linux so much better).
I wasn't joking. The Unix systems often copy neat features from one another when one innovates ahead of the others. I have a pending patch for Linux copying OpenBSD's O_NOSIGPIPE option but I have yet to finish it. > > Do you realise that the cost of starting a thread is much higher than the > > cost of a pipe? Not to mention that using QThread will create a pipe > > anyway, so you'd need to drop down to low-level primitives (pthread, > > Win32) to get away from it. > > OK, that's an argument. I tried to figure that out and didn't see evidence > that QThread *always* creates a pipe. Pity but thanks for confirming. It's not QThread itself, it's the event dispatcher. Either QEventDispatcherUNIX, QEventDispatcherGlib or, on a Mac, QEventDispatcherCoreFoundation. But looking at the sources, it seems that the event dispatcher is created on-demand by the first QEventLoop or by calling exec(), so the file descriptor won't be opened until then. > > You could pre-allocate the event before the signal and then you can > > transfer ownership. But postEvent() still needs to manage a queue and > > that may need to > Exactly, which is what I realised when I saw it locking a mutex. Right, it also locks a mutex, which is also why it could deadlock. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
