Yeah… If your bindings have some function which indicates that there is some
data available, it’s trivial…
Well the socket knows when there’s read data available, just as with
selects. Looks like it could listen to that, meaning no problem at
all.
So sync return in the thread you start them in, but async run them in the dbus
thread or does it spawn another one ?
Every async call must by definition run in it’s own thread, otherwise
it’s not very async :). The actual message passing is in one single
thread so there’s no race conditions though.
Yeah… If your bindings have some function which indicates that there is some
data available, it’s trivial…
Well the socket knows when there’s read data available, just as with
selects. Looks like it could listen to that, meaning no problem at
all.
So sync return in the thread you start them in, but async run them in the dbus
thread or does it spawn another one ?
Every async call must by definition run in it’s own thread, otherwise
it’s not very async :). The actual message passing is in one single
thread so there’s no race conditions though.
nothing new in the last week or so, since I’ve been busy with other
things, but there is a release up on Rubyforge with everything
client-side except exporting objects, which is the next thing. Also
there’s a bunch of examples, including an implementation of dbus-send
(rbus-send) and a tutorial and API docs. Still not 100% sure on the
API, input is welcome.
You can also get it with “gem install rbus”.
Feel free to give it a spin and let me know what you think, any
input/contributions are welcome. There’s bug trackers, forums, lists
and stuff like that on the project page, or you can just email me.