C convenience lib (was Re: Is dbus_pending_call_set_notify() thread safe?)

[Havoc Pennington]

Hi,

Fan Wu wrote:
> I am not disagreeing with you that my proposal is not a NEW model. Let
> me put it this way, theoretically it's the same as 1)b, but it
> simplifies user interface in that user does not need to deal with DBUS
> related looping (threads or mainloop). It's not meant to be completely
> transparent in hiding the async nature of the model, but hopefully
> users can write less code and still get things work. Convenient,
> that's all.

I'm all for working on some convenience API here, in my other mail I was 
just trying to unpack the issues - I think the most convenient API is a 
pretty big and separate discussion, vs. the smaller matter of fixing the 
bug about waking up a blocking thread.

The only point I was trying to make about the convenience API is that it 
should be possible to implement "on top of" libdbus, rather than 
requiring libdbus changes, at least for an initial proof of concept. 
That's why I was writing about how it isn't a new model, I was trying to 
explain that it's a model libdbus already allows you to use.

> The backend can be a thread running a mainloop, or a thread blocking
> of dbus_connection_read_write_dispatch(). With the latter approach,
> the bug as you mentioned has to be fixed. A workaround is too have two
> connections and each with its own thread, but that's just too complex.
> I'm working on a patch to fix the bug and will post it here by the end
> of this week. What the patch does is to make the poll/select
> interruptible, so that whenever a write initiative fails in
> acquire_io_path, AND the transport is blocking in the poll call, the
> blocking will be interrupted. The patch will be for client only.

Thanks for working on this!

You might consider whether to do this exactly parallel to the current 
wakeup_mainloop usage. That is, essentially add a wakeup_mainloop for 
dbus_connection_read_write_dispatch() (which internally ends up being 
the iteration() functions).

There should not be a bug right now if the blocking thread is blocking 
in a main loop, because of the wakeup main function.

So if we make the poll() in dbus-transport-socket.c block on a pipe 
also, then we can have an iteration_wakeup() for it.

Instead of a pipe we could use unix signals, but I would be afraid of 
potential weirdness and side effects from that, since libdbus is a 
library not an application and may be used from many contexts.

We would invoke the iteration_wakeup() whenever n_outgoing > 0 after 
attempting to acquire the IO path.

There may be some trickiness, e.g. we might have to ensure the wakeup 
pipe does not fill up even if nobody ever makes a blocking call.

Or this whole approach might not work, but I'm just throwing it out 
there. I think the more we can treat the dbus internal iterate() stuff 
as "just another main loop" the better.

Havoc