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

[Fan Wu]

HI Havoc,

The bug fix is just to make the implementation of the proposed API
easier. Please don't take it as the whole picture. I was just throwing
out some thoughts. My experience with DBUS is limited and I really
need to work out a prototype before I talk more about it. It may ends
up a totally different beast.

Re the bug fix, I think it's not quite the same as that for
wakeup_main because wakeup_main is called for both incoming and
outgoing traffic, while the bug fix is exclusively for outgoing
traffic. Right now the wakeup_poll is only called in
_dbus_connection_do_iteration_unlocked() when the flag has
DBUS_ITERATION_DO_WRITING in it. Most of the DBusConnection functions
are not aware of the fix at this time. It's not cast in stone can
definitely be changed. One question I have is do we need to expose an
API at the user level so that the blocking call can be interrupted
when the application is about to exit?

For your other concern, the wakeup_poll function will only be called
if the socket is blocking in poll/select. Also every time after the
poll exits the wakeup pipe will be checked and will be drained if
there is stuff in it.

Thanks,
Fan

On 8/2/07, Havoc Pennington <hp at redhat.com> wrote:
> 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
>
>