Questions about some implementation ideas for a language binding ...

rony rony at
Sun Jul 3 06:26:56 PDT 2011

Hi there,

being in the middle of creating a language binding for a scripting
language called ooRexx (cf., there are quite a
few possible turns I could take in the implementation.

First, this language binding will run its own message loop. The message
loop is realized with a "while
(dbus_connection_read_write(conn,milliTimeout) ) {...}" running on its
own thread.
[If ooRexx clients call methods on other objects, this is carried out
with the thread-safe "dbus_connection_send_with_reply (conn, dbusMsg,
&pendingMsg, -1)", which should be totally independent of the
potentially in parall executing dbus_connection_read_write() loop.]

Currently, the message loop will be started on a new thread, if listener
or service objects get registered with the connection and the loop was
not running at that point in time.

In addition, currently the programmer may start, query, stop this
message loop at her will.

1. So the first question to those in the know would be: is this in
principle o.k.? Or are there pitfalls a rookie like myself is mostlikely
not seeing/realizing?

2. As the user is able to turn the message loop on and off, would
messages between turning off and on be cached in the input message
queue? If so, could one empty the input message queue easily (what
APIs?) or would I have to just process/read the input message queue,
before restarting  the message loop processing?

2.a. Contemplating of allowing "fail over service object" behaviour: in
this case it is probably not wise to ignore any messages that may be in
the input queue, as it may be the case that some messages are meant for
the service object, since the last time the message processing was stopped?

2.b If unregistering listener and service objects, how should I stop the
message loop processing; is there some established procedure for that?
What if new listener and service objects get registered later and the
message loop gets restarted (that's probably the same question as above) ?

3. Possible assumption: if not executing the message loop unprocessed
messages get discarded by "sane" timeouts, such that I should not bother
with piled up messages in the input message queue at all?

Any answer/feedback/thoughts highly welcome as at this stage it is
rather easy to change the implementation!



More information about the dbus mailing list