Replacing evil looping code

[uwesmail2005-lkml at yahoo.de]

--- Bastien Nocera <hadess at hadess.net> schrieb:

> Hey Havoc,
> 
> On Mon, 2006-11-06 at 10:12 -0500, Havoc Pennington wrote:
> > Hi,
> > 
> > > Is it possible to replace all that crap with decent D-Bus code?
> > > 
> > > I don't think we can use a service, as we're depending on some
> > > command-line arguments (should we pass those to the service in
> some
> > > other way instead?).
> > 
> > Remember you can autostart a service by just sending it a method
> call, 
> > so if your command line args can be args to a method that might
> work.
> 
> I figured that much. But see below.
> 
> > The showstopper for using a service in your case looks like the
> dynamic 
> > bus name creation (putting the pid in there), there's no way to put
> the 
> > dynamic bus name in the .service file.
> 
> To be fair, we don't really need that "PID" bit, but we'd need one
> instance of the service per instance of our plugin in Mozilla (well,
> pretty much).
> 
> If we can that one-to-one relationship without using a dynamic
> service
> name, it wouldn't bother me one bit to use it. I didn't see any ways
> to
> have that using the service route.
> 
> > If you figured a way around that, then just calling 
> > dbus_connection_send_with_reply_and_block() (or glib equivalent)
> would 
> > be what you want; it would send a method call, which would block
> until 
> > the service started up, and then return.
> 
> Nod.
> 
> > Otherwise, your code doesn't seem that horrible to me, it's pretty
> much 
> > the usual "block in main loop code" (looks about the same as 
> > gtk_dialog_run() for example). I usually try to avoid this and just
> do 
> > things asynchronously, but I'm guessing your code is in some scary 
> > mozilla context that makes that difficult...
> 
> Well, Christian Persch really dislikes it, and I can fully understand
> why :)
> 
> > dbus could have a dbus_connection_block_for_signal() call, but it
> might 
> > be somewhat dangerous; unlike method call replies, signals aren't 
> > usually very reliably known to be about to arrive, and dbus does
> not 
> > block in a reentrant way so the app would be locked up...
> 
> Expecting signals is always a bit worrying, when you're not 100% sure
> it's going to arrive :)
> 
> As I said, if there was a way to differentiate instances of the same
> service, we'd be in business using the services activation.
> 
> Any ideas welcome.
Here is my idea: use the totem-name(w/o pid) to receive a call to a
execute method (that is to get the args). Then in that method
give up that name and assume the one with pid. On return you give
back the pid so the caller can change its idea of the service name.
in short: On startup connect to the bus w/o PID then change the name.
> 
> Cheers
> 
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
> 



		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de