[Telepathy] telepathy-glib: *_run_* methods.

[Xavier Claessens]

Hello,

Some problems with *_run_*:
1) If used inside a dbus signal callback, your mainloop get blocked and
you'll never receive your reply.
2) If used inside a dbus method implementation you get the same as in 1.
3) It looks like sync call but it is really not, so you have to be
really careful.
4) If you make too much run calls you'll get a really big call stack.
This is not efficient and makes crash debug more difficult.
5) gtk_quit() won't work while waiting for a reply, you'll have to wait
for all calls to return before your program exit. If new calls are made
after gtk_quit(), you'll have to wait for them to return too. If you are
in the case 1 or 2, your program will even *never* quit.

IMO run API should be avoided. It only makes easier to write quick test
code, but real sync (blocking calls) is even easier and safer in that
case.

Xavier Claessens.

Le mardi 18 novembre 2008 à 11:08 +0100, Murray Cumming a écrit :
> It's been suggested that people should just never use the run functions
> such as tp_cli_connection_run_request_handles(), because these are
> really asynchronous operations.
> http://telepathy.freedesktop.org/doc/telepathy-glib/telepathy-glib-connection.html#tp-cli-connection-run-request-handles
> 
> However, these functions won't block the main mainloop, right. For
> instance, they won't prevent a GTK+ application from responding to
> button clicks. Or am I wrong?
> 
> And if you supply a secondary mainloop then you can cancel a run
> function if some user input makes that necessary.
> 
> So the use of these functions really doesn't seem that awful. If you
> really know that there's nothing else you need to do while waiting,
> other than responding to user input, then they seem like a sensible way
> to simplify your code.
> 
> The only problem I can see is that the run functions make it difficult
> to make various requests to telepathy in parallel, but how common is
> that?
> 
> Opinions?
>