Gentoo Archives: gentoo-guis

From: "René 'Necoro' Neumann" <lists@××××××.eu>
To: gentoo-guis@l.g.o
Subject: Re: [gentoo-guis] One backend for alle portage GUIs
Date: Fri, 02 Nov 2007 17:49:23
Message-Id: 472B6306.8010201@necoro.eu
In Reply to: Re: [gentoo-guis] One backend for alle portage GUIs by Luis Francisco Araujo
-----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