| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Luis Francisco Araujo schrieb: |
| 5 |
> René 'Necoro' Neumann wrote: |
| 6 |
>> Hey, |
| 7 |
> |
| 8 |
>> I have to admit: Catapult did not work as expected. I wrote, that I used |
| 9 |
>> it in Portato. But this wasn't correct as I saw today - after doing two |
| 10 |
>> dbus calls he switched to the normal backend. I fixed that and |
| 11 |
>> discovered several bugs, which got fixed. I also managed to put the |
| 12 |
>> "update_world" call into an extra thread, so it does not block the whole |
| 13 |
>> daemon if it is called. - More calls will follow. I don't know if it is |
| 14 |
>> a good idea to do so with all calls (overhead?) or if only selected |
| 15 |
>> calls should get their own private thread. |
| 16 |
> |
| 17 |
>> Regards, |
| 18 |
>> Necoro |
| 19 |
> |
| 20 |
> Can you explain what problems did you have? |
| 21 |
> |
| 22 |
> I just could glanced over some irc logs saying that was because of DBus |
| 23 |
> not being smart enough to handle different process in parallel? |
| 24 |
> |
| 25 |
> Regards, |
| 26 |
> |
| 27 |
The main problem was as following: |
| 28 |
|
| 29 |
If client A starts a time consuming process (e.g. update_world), the |
| 30 |
server blocks all following requests (regardless which client has sent |
| 31 |
them) until the process has finished. |
| 32 |
This could be solved by making the call asynchronous on server site: |
| 33 |
The function gets two callbacks (one for success, one for error). Then |
| 34 |
it can launch a thread doing the calculation which calls the appropriate |
| 35 |
callback eventually. So the function can return immediately and other |
| 36 |
calls are not blocked. |
| 37 |
|
| 38 |
Finding this was not the problem - it just did not work. After two hours |
| 39 |
I finally figured out, that I have to explicitly allow threads for glib. |
| 40 |
So this was more kind of a python/glib problem and not a dbus one. |
| 41 |
|
| 42 |
A second problem: |
| 43 |
If a client calls a time consuming process, it could happen that the |
| 44 |
dbus call times out (i.e. the server takes too long to get the answer). |
| 45 |
This can be easily solved by making the call asynchronous on client site. :) |
| 46 |
|
| 47 |
Another problems/bugs were minor and trivial ones. |
| 48 |
|
| 49 |
Regards, |
| 50 |
- - Necoro |
| 51 |
-----BEGIN PGP SIGNATURE----- |
| 52 |
Version: GnuPG v1.4.7 (GNU/Linux) |
| 53 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
| 54 |
|
| 55 |
iD8DBQFHK2MG4UOg/zhYFuARAuRoAJwMuyntpRlLqoSMduEljanWnRvq+gCeLIyL |
| 56 |
cmzlowE0nAm612gjPoM6fvM= |
| 57 |
=oFtc |
| 58 |
-----END PGP SIGNATURE----- |
| 59 |
-- |
| 60 |
gentoo-guis@g.o mailing list |
Archives