On Mon, Oct 30, 2017 at 3:32 PM, Daniel Mach <dm...@redhat.com> wrote: > > > On Mon, Oct 30, 2017 at 2:02 PM, Colin Walters <walt...@verbum.org> wrote: >> >> On Mon, Oct 30, 2017, at 07:43 AM, Neal Gompa wrote: >> > * Using C++ makes glib2 usage mostly pointless, as glib2 is by and >> > large replaced by the C++ STL. The only advantage of GLib2 is GObject >> > Introspection >> >> Not quite; there's also the main event loop, which is also tied into >> infrastructure like file monitoring (used today in libdnf to monitor >> the rpmdb), and what are effectively "sub-libraries" in libglib >> like GDBus. For example today dnf talks to NM via pydbus: >> >> https://github.com/rpm-software-management/dnf/blob/master/dnf/util.py#L261 >> which is currently synchronous, but any nontrivial usage >> requires a main loop (which pydbus uses glib's most commonly). >> >> And the whole "async" infrastructure in GTask is based on this. >> Now, libdnf today is mostly synchronous, which is OK. We could >> keep it that way. > > Libdnf will most likely remain synchronous, > but thanks for bringing this topic up. > Making another note... >
What prevents us from handling async things with libdnf? >> >> In fact for various reasons we're highly likely at some point >> in the future to change rpm-ostree to mostly use librpm/libdnf >> from a subprocess. >> >> One of those reasons is that librepo doesn't currently use any >> of the GIO bits, notably GCancellable: >> >> https://github.com/projectatomic/rpm-ostree/issues/897#issuecomment-318427563 >> >> This doesn't matter for a command line tool, but it matters a lot >> for a daemon. So by changing our libdnf to be in a subprocess we're >> basically reworking the architecture to be daemon → internal command line. >> >> But, even if we do this, we'll need to do things like have progress >> on downloads be emitted via some internal messaging framework >> (probably private DBus socket). I think that'll be fine if things are >> generally >> synchronous in libdnf, but if we're talking about redoing libdnf >> I think we need to keep these high level architectural bits in >> mind and not just focus on the programming language. >> If we're considering rearchitecting libdnf (albeit slowly), we should consider making it so that things like rpm-ostree don't need to force a subprocess model for asynchronous operations. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
