Re: sdbus errors and their underlaying int value: unique?

[Carlo Wood <carlo@xxxxxxxxxx>]

On Thu, 4 Mar 2021 10:46:43 -0300
Cristian Rodríguez <crrodriguez@xxxxxxxxxxxx> wrote:

> On Tue, Mar 2, 2021 at 7:55 AM Carlo Wood <carlo@xxxxxxxxxx> wrote:
> 
> > On Tue, 2 Mar 2021 10:40:25 +0100
> > Carlo Wood <carlo@xxxxxxxxxx> wrote:
> >  
> > > I'm not writing my own C++ wrappers around sbus.  
> >
> > I'm now* writing my own C++ wrappers around sbus.
> >
> >  
> JUst curious..what is wrong with QTDbus.. ? I strongly suggest you
> against the path of reinventing this particular wheel.

I started off with sdbus-cpp, and that turned out to be
inflexible and not suitable for my application without
cloning their repository and making changes.

At some point I just got tired of working around issues.
One of the main reasons that I decided to completely stop
using it is because they use a mutex to make sure only
one thread enters the library at a time; which is not how
I work (I use mutexes, but don't hold them so long that
there is a reasonable risk that they are still locked
when another thread tries to lock them; at most a few
assembly instructions). But at least as important is
that is creation of new threads and/or blocking system
calls seemed completely intractable. Sdbus-cpp is doing
way more than just wrapping systemd's sdbus and most of
it I don't want.

I never considered QTDbus because well, I'm not using Qt.
I supposed that Qt had the same problems as me: wanting
to have sdbus under their own main loop control AND support
for C++ - hence being forced to write their own wrapper.

But that then (I assumed) would be Qt specific top to
bottom; using Qt stuff whenever suitable and a requiring
to have a Qt main loop. If I was mistaken at that then
that is unfortunate.

Regards,
Carlo Wood.

PS Same story for GDBus. GLib has the tendency to be
a COMPLETE solution - using glib stuff everywhere. And
I am not using glib (my library is ALSO a complete
solution by the way; with -as said before- the emphasis
on being scalable to arbitrary many cores and avoiding
any and all blocking of threads.



_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel