dbus & threading (fix) ...

[Michael Meeks]

Hi Colin,

On Mon, 2010-03-08 at 10:00 -0500, Colin Walters wrote:
> On Mon, Mar 8, 2010 at 5:56 AM, Michael Meeks <michael.meeks at novell.com> wrote:
> >        Is there any chance we can get a new release of dbus-1 with the fix, so
> > that we can depend on in the next two weeks ?
> 
> That's a really short timeframe for such a fundamental change; I'm not
> opposed but  I'd like to think through a bit about what the possible
> regressions are.

	Of course !

> Couldn't this patch cause messages to get delayed until a subsequent
> message comes in?

	I hope not :-) there are a number of possibilities wrt. the overlap
between the threads; here is my condensed thinking, the main-loop is
essentially racing against another thread that is doing I/O. That other
thread looks like:

	1. take io_path mutex
	2. do I/O - socket_handle_watch - calls
		dbus_transport_queue_messages eventually queueing a
		main thread wake-up[1]
	3. release io_path mutex

	Now; considering the main thread racing against this. If that thread is
executing code, then steps 1->3 can happen without it ever noticing
while the main thread is busy re-calculating spreadsheets. This is the
path we trigger when we sleep for 1ms on the io_path mutex and then spin
the main-loop.

	I suppose the only newish thing that can happen here is that we get a
sequence whereby the main thread's condition wait completes between step
2. and 3. Potentially in that case we might leak a 'wakeup' that would
have triggered the dbus-glib message_queue_source to process an incoming
message.

	However - in this case, since we are waiting for the io_path
mutex/condition as a child of the mainloop anyway - we can be certain
that we will get another spin around that loop after we complete. So -
at least for the glib case, this will not cause any problems.

	Of course, if some other main-loop exists that manages to call
_dbus_connection_handle_watch outside of a watch, in a loop that will
not iterate again and process events when woken up there might be
problems: but that would be a pretty unusual loop.

	I had a quick read of Qt. It seems they don't register a wakeup
function at all: dbus_connection_set_wakeup_main_function appears to be
un-called, nor do they call get_dispatch_status. As such, I suspect that
their binding is not thread-safe anyway - so hopefully will be
un-affected by this - though of course my understanding there is
somewhat shallow.

>   If we return from the watch in main thread #1
> without doing anything, then the thread #2 finds its reply and handles
> it, thread #1 will not process the queue again until another message
> comes in and triggers the watch again, correct?

	Well - if that was the case we would have a serious bug - since it is
quite possible that thread #2 can find and handle a reply while thread
#1 is away doing it's own processing (cf. above) - so this should be a
fairly normal and well tested case.

> On the other hand this is clearly better than just blocking in thread #1.

	Quite, so - does the above blurb make you happier ? :-) certainly it
makes me so, having had to read & understand the socket code a little
more.

	Thanks for asking the right questions,

	Regards,

		Michael.

-- 
 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot