Tracking DBusWatches

[Thiago Macieira]

tsuraan wrote:
>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
> activity? 

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 
too many.

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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20070209/1ca0dff2/attachment.pgp