Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-guis
Navigation:
Lists: gentoo-guis: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-guis@g.o
From: René 'Necoro' Neumann <lists@...>
Subject: Re: One backend for alle portage GUIs
Date: Fri, 02 Nov 2007 18:48:54 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Luis Francisco Araujo schrieb:
> René 'Necoro' Neumann wrote:
>> Hey,
> 
>> I have to admit: Catapult did not work as expected. I wrote, that I used
>> it in Portato. But this wasn't correct as I saw today - after doing two
>> dbus calls he switched to the normal backend. I fixed that and
>> discovered several bugs, which got fixed. I also managed to put the
>> "update_world" call into an extra thread, so it does not block the whole
>> daemon if it is called. - More calls will follow. I don't know if it is
>> a good idea to do so with all calls (overhead?) or if only selected
>> calls should get their own private thread.
> 
>> Regards,
>> Necoro
> 
> Can you explain what problems did you have?
> 
> I just could glanced over some irc logs saying that was because of DBus
> not being smart enough to handle different process in parallel?
> 
> Regards,
> 
The main problem was as following:

If client A starts a time consuming process (e.g. update_world), the
server blocks all following requests (regardless which client has sent
them) until the process has finished.
This could be solved by making the call asynchronous on server site:
The function gets two callbacks (one for success, one for error). Then
it can launch a thread doing the calculation which calls the appropriate
callback eventually. So the function can return immediately and other
calls are not blocked.

Finding this was not the problem - it just did not work. After two hours
I finally figured out, that I have to explicitly allow threads for glib.
So this was more kind of a python/glib problem and not a dbus one.

A second problem:
If a client calls a time consuming process, it could happen that the
dbus call times out (i.e. the server takes too long to get the answer).
This can be easily solved by making the call asynchronous on client site. :)

Another problems/bugs were minor and trivial ones.

Regards,
- - Necoro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHK2MG4UOg/zhYFuARAuRoAJwMuyntpRlLqoSMduEljanWnRvq+gCeLIyL
cmzlowE0nAm612gjPoM6fvM=
=oFtc
-----END PGP SIGNATURE-----
-- 
gentoo-guis@g.o mailing list


References:
One backend for alle portage GUIs
-- René 'Necoro' Neumann
Re: One backend for alle portage GUIs
-- René 'Necoro' Neumann
Re: One backend for alle portage GUIs
-- Luis Francisco Araujo
Navigation:
Lists: gentoo-guis: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: One backend for alle portage GUIs
Next by thread:
Re: One backend for alle portage GUIs
Previous by date:
Re: One backend for alle portage GUIs
Next by date:
Re: One backend for alle portage GUIs


Updated Jun 17, 2009

Summary: Archive of the gentoo-guis mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.