fall into afb_api_call_sync
Description
Environment
Attachments
Activity
Close for GG 7.0.1
I just checked and yes that is also a problem in guppy. I'm cherry picking it.
Is this an issue in guppy as well? Should we cherry pick?
Thanks for testing the patch. I pushed the change to meta-agl expecting the fix to land quickly.
About call/subcall, note that hi3.c is removed since 31 december 2018. The reference example is hello3.c. These examples are not well documented.
call and call_sync are not bound to requests (and are prefixed by afb_api_, they need an api_t).
subcall and subcall_sync* are bound to requests (and are prefixed by afb_req_).
In your case, the call is done in both circumstances. Doing an asynchronous call in the scope of a request is technical. You have to add/sub reference to the request. You can find the example from line 345 to line 360 in hello3.c.
In the case of asynchronous subcalls, the binder manages it automatically for bindings v3.
In your case, as the call to afmain is encapsulated in the wrapping object, you dont directly know wether a call or a subcall should to be done. You could write 2 methods, one with a request and the other without. But as the same question will be raised later in other contexts by other people, the correct solution concerning your issue is that the binder accept synchronous calls in events.
Thanks for detailed explanation.
I had tested 20491 patch, it's ok.
1. About afb_api_call api, I looked over the sample in hi3.c, I found that the request(afb_req_t) was set in closure, so I had a question, whether I can fix the request in a structure as below:
struct st_cb {
afb_req_t request;
others; /* variables which defined in service */
};can I set either values or pointers in "others"? then used this structure in callback function?
Details
Details
Assignee
Reporter
Fix versions
Contract ID
Priority
Major
As the title, when I tested my program in lastest master environment, I found this issue. The test procedures as below:
1. use "afm-util install xx.wgt" to install new application
2. look at launcher application for checking whether application list is updated.
The result was not update.
From the journalctl log I found that when homescreen-service received application-list-changed event from afm-main it tried to get runnalbes list from afm-main, then it falled into "afb_api_call_sync" api. But when I used old version master environment (2018/12/18) , homescreen-service didn't fall into "afb_api_call_sync".
Upper description may not be easy to understand， please reference error_sequence.png.
related source
related jira
I had two issues as below:
1. why in lastest version homescreen-service could fall into "afb_api_call_sync" when received "application-list-changed" event?
2. how can I rollback af-main and af-binder to old version in lastest master environment?
2019-03-06 :
I changed af-binder version to "Remove useless %lang% prefix in yaml book file" at 2018-12-19, then this issues didn't happen, but the application starting speed became slow.