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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
