Re: [SyncEvolution] Recursive mainloop in SoupTransportAgent
On Thu, 2009-11-12 at 02:45 +0000, Chen, Congwu wrote:
>How does it work with the outer mainloop? Does it mean during
wait() the
>outer
>mainloop is freezing? I am inclined to this and this is not desiable.
Ah, no. They are associated with the same context, so the inner loop can
check sources associated with the outer loop before.
With context you mean the GMainLoop pointer, right? That's indeed
intentionally the same for all g_main_loop_run() calls, so that D-Bus
method calls can be processed while waiting for network packets.
I'm not entirely happy with this solution because it is so unintuitive
and complex. But getting rid of it is hard and won't work in all cases.
First, the SyncContext API needs to change so that instead of blocking
in sync(), it needs a setup/process/finalize kind of API where "process"
just gets an incoming message and returns the response. Then the layer
above it can integrate message transportation into the main event loop.
Second, backends must not block. If they have to block, they must set up
events in the main loop and return control, to continue once the event
occurs.
This is were we have a problem: because backends are called through the
Synthesis engine, backends don't have the possibility to return control.
Suppose the engine calls "read item" and expects the data as return
value. We are stuck in that call chain and can't return until the data
is available.
Then there might be backends which access data which is only available
through blocking API calls. In that case even rewriting the whole
Synthesis engine and its database API wouldn't help.
Event-driven systems are good from a performance and concurrency
perspective, but they are hard to use unless all components are designed
around that model from the start. So I think we'll have to accept that
and work around the limitations as well as we can.
Perhaps multithreading can help: not for truly running syncs in
parallel, but to preserve the call chains and context when switching
between different activities. I'll think about this some more.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.