thiago at kde.org
Fri Feb 9 14:22:52 PST 2007
>So the "correct" solution is to basically ignore read_write_dispatch and
>implement the exact same thing, but with an additional socket that's
> used just to wake up the thread that's waiting for file descriptor
No. The correct solution would be a proper mainloop implementation.
There's no need for an extra thread.
If you prefer to use a thread, you need a communication mechanism. That's
where the pipe comes in.
That's hardly hackish at all, since both major toolkits use that for
waking up mainloops. In fact, as far as I know, that's the only way of
properly and reliably interrupting a select(2)/poll(2) call. (With a
signal, you don't know if the signal was delivered on time or if it
interrupted the system call)
If we make dbus_connection_read_write support waking up from other
threads, that's how we'll do it.
> It seems like you have a handful of instructions to check
> the message queue's state, and then you go back to polling for another
> hundred ms.
Remember that you're comparing that to no activity at all. If it takes 2
minutes for the next message to come in, your program woke up 1199 times
Now imagine that being done constantly by 10 programs. I call that
unacceptable load when a proper solution is available.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20070209/1ca0dff2/attachment.pgp
More information about the dbus