Re: [SyncEvolution] server class + fork/exec dbus-server

2012/3/19 Patrick Ohly <patrick.ohly(a)intel.com&gt;: > On Mon, 2012-03-19 at 11:33 +0100, Krzesimir Nowak wrote: >> 2012/3/16 Patrick Ohly <patrick.ohly(a)intel.com&gt;: >> > On Fri, 2012-03-16 at 13:52 +0100, Patrick Ohly wrote: >> > >> > Krzesimir, you can document and rename the callbacks in parallel. Please >> > base it on the concurrent-sync-pohly-delayed-dbus branch. >> > >> >> It is in https://meego.gitorious.org/~krnowak/meego-middleware/krnowaks-syncevolut... >> >> I also started refactoring Resources to have: >> - clean ownership situation when creating resources, >> - resources tracking in signals >> - additional callback for case when creating resource failed after >> spawning a sync-helper. >> >> The branch is https://meego.gitorious.org/~krnowak/meego-middleware/krnowaks-syncevolut... >> but I recommend not merging that, because I have to investigate why >> some session test are now failing. >> >> I was also thinking that we should use boost::slot instead of >> boost::function for callback for tracking purposes. But if that is >> needed then it may be done after I am done with the things above. > > Thanks for the changes. I'll have a look at them as part of my own code > changes. Don't worry about the failing tests for now. The problem might > resolve itself as part of the work that I am doing. Hi, I just did forced push to my cssr1 branch with some fixes in refactoring I did - apparently boost::signals does not immediately clean up disconnected slots, which ended in keeping reference to session resource. Thus client was not calling some code on detach, because shared pointer was not unique. For now the test below fails (but they I remember they passed before): TestLocalSync.testConcurrency TestLocalSync.testPasswordRequest TestLocalSync.testSync TestSessionAPIsDummy.testInteractivePassword I don't know if these failures are related to my refactoring.

> -- > 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. > >