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). > 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. > "just allocate in the actual signal handler" is exactly what you mustn't do, > since malloc() is not async-signal-safe. You can deadlock or corrupt memory if > you try that. The actual signal handler, the one that does the things you want to but cannot do in the, erm, signal handler. Sorry for the confusion. > 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. R _______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
