[SyncEvolution] GDBus C++ add_filter + fork/exec dbus-server

Patrick Ohly patrick.ohly at intel.com
Fri Mar 16 02:58:31 PDT 2012


On Thu, 2012-03-15 at 18:06 +0100, Krzesimir Nowak wrote:
> W dniu 15 marca 2012 17:54 użytkownik Krzesimir Nowak
> >> So it seems to me that this is the right way to go. Regarding the code,
> >> can we introduce flags for dbus_get_bus_connection() instead of creating
> >> multiple copies of it? That'll scale better in case that we find a need
> >> for other variations.
> >
> > That is almost exactly what I did - but instead of adding flags I just
> > added a bool parameter. Right now I am creating some commits. I will
> > let you know when I push this.
> 
> Pushed here (forced update):
> https://meego.gitorious.org/~krnowak/meego-middleware/krnowaks-syncevolution/commits/css-with-direct-msg-proc

Note that nothing in your GDBus C++ commit messages or code explains
what "delayed connection" is, and how it might be used. Please remember
to include explanations to the code (as API description) and/or commit
messages (to give additional information). I've merged that into
concurrent-sync-pohly anyway. Instead of removing the dead code
manually, I dropped the commits which introduced it from the branch.
Result is in concurrent-sync-pohly-delayed-dbus.

In which case would it be useful to use ForkExecChild::connect(delayed =
false), the default? I can't think of any, and thus would always delay
internally. Even if the we keep the parameter, the default is dangerous
because it leads to the race condition and thus should be the other way
around.

The new branch uses the -resource variant of naming the session and
connection class in the syncevo-dbus-server side. I ended up using that
because it had less conflicts with the changes that I had made for
password handling - so a purely pragmatic decision. I'm still not happy
with the naming, but that can wait.

Please base all future work on that.

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





More information about the SyncEvolution mailing list