Hi Jussi
I've mentioned about such an approach earlier, when I propose
asynchronous API.
What You need is single threaded asynchronous API. As for many other
possible applications/services based on glib main loop You need
asynchronous calls that probably return a descriptor that You can attach
to Your main loop and when it is ready for read, run another cynara
function that will extract and interprete data.
I remember about asynchronous API, but I would like to leave
implementation of it for further releases and now focus on
cynara-daemon-based version.
Best wishes
Lukasz
W dniu 2014-05-20 16:53, Jussi Laako pisze:
On 20.5.2014 0:21, Patrick Ohly wrote:
I plan to clean up properly when the process shuts down. This includes
calling cynara_finish() ("should be called once before exiting
service"). Once I do that after having introduced threading, I need to
know what happens when there is a parallel cynara_check(), or whether I
am expected to avoid this situation.
If I'd ever implement Cynara support to gsignond which is driver by
glib mainloop but not multi-threaded (and not planned to be), I'd need
to ask how to launch multiple parallel cynara_check()'s in parallel.
Because we dispatch calls to different plugin processes
asynchronously, thus handling new requests for other methods before
plugin process completes the previous one.
If cynara_check() can block for UI, then dbus call will timeout after
30 seconds and it could mean a completely unrelated client request
timing out.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
