using the wakeup_main_function together with dispatch_status_function

[Havoc Pennington]

Hi,

On Thu, Sep 25, 2008 at 4:02 AM, jim harvey <jimharvy at gmail.com> wrote:
> i've currently removed the use of both functions (set_dispatch_status and
> set_wakeup_main) and i'm using the
> my_wakeup_main() function (which i've written as you said) to wake up the
> main loop in case a new timeout/watch is toggled/added.
> i use this setup and dispatch in the mainloop while DATA_REMAINS.
> in this use case, is there need for any of the notifications (dispatch
> status change or wakeup main)?

I would not expect that a watch is guaranteed to be toggled or
added/removed in all cases that there may now be stuff to dispatch,
for example the main socket read watch is never toggled or removed
afaik until the connection is closed.

iirc dispatch status function was added because in some cases messages
could appear in the incoming queue even though dbus_watch_handle()
hadn't been called. Originally you were supposed to just always
dispatch after handling a watch. I don't remember what the cases are.
One example might be a timeout expiring resulting in a synthetic error
message created on client side.

An example given in the reference docs for wakeup main is that if a
message is queued for writing but can't be written immediately, the
main loop has to be kicked awake to add the write fd to its poll(). In
this case the watch probably does get toggled.

The API contract is certainly that you should implement all of these
callbacks, to know for sure on what you can get away with outside of
the contract, you'd have to carefully review the source and see what
the current situation is, then hope that situation does not change.

> also - in your description of the wakeup_main function, are you implying
> there is a default function called to wake
> up the mainloop if i don't provide one? i haven't seen such in the source
> code. Are you simply referring to what is done by the standard
> DBusWatch-es mechanism?

No, I guess I was describing what the GLib wakeup main function would
do (and afaik the only sane way to implement a wakeup main function on
unix).

> My service does not issue method calls, only responds to method calls from
> clients (and issues method returns)
> and omits the occasional signal. can this explain the lack of timeouts i'm
> experiencing?

Quite likely.

Havoc