Re: [SyncEvolution] server class + fork/exec dbus-server
On Tue, 2012-03-20 at 12:21 +0100, Krzesimir Nowak wrote:
2012/3/20 Patrick Ohly <patrick.ohly(a)intel.com>:
> On Tue, 2012-03-20 at 11:46 +0100, Krzesimir Nowak wrote:
>> [ERROR syncevo-dbus-helper 00:00:00] sending message to child failed:
>> org.freedesktop.DBus.Error.UnknownMethod: No such interface
>> `org.syncevolution.localtransport.child' on object at path /
>>
>> Looks like something is racy.
>
> Probably the same issue as for
> syncevo-dbus-server<->syncevo-dbus-helper, but now between
> syncevo-dbus-helper<->syncevo-local-sync. See my email about not always
> using delayed message processing in ForkExec - syncevo-local-sync still
> starts processing right away, because its call to ForkExec was not
> updated yet.
>
> In my current work branch I have merged your ForkExec patch without the
> "delayed = false" parameter.
Ah, right. I thought that you already did that for
concurrent-sync-pohly-delayed-dbus upon which my work is based.
I am now wondering if I should now try moving some common code from
session resource and connection resource to base class.
Please stop for now. You'll end up duplicating work.
I read that
you are trying to move connection stuff to server and that would end
with not using sync-helper for it, that is - connection resource
itself would disappear I think.
Exactly. Connection and AutoSyncManager depend on common state
information (presence, session history). That state information should
stay in the syncevo-dbus-server together with the main logic in these
classes, to avoid constantly calling out to some helper.
--
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.