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 |