Re: Synchronous method in asynchronous signal callback

On 14/05/15 18:10, Marco Bascetta wrote:
> My goal is to create a library for various systems that already have
> their own (working) mainloop based on poll, epoll or libevent.

My apologies for this slightly off-topic rant, but it's something that
comes up reasonably frequently...

I know how appealing this is: everyone wants minimal dependencies, and
everyone wants to be able to attach the magic word "lightweight" to
their modules. A lot of people also want portability, because it's
annoying when you can't have a useful piece of software because it only
works on Linux, or only on Linux and *BSD, or only on OSs that are
basically POSIX (i.e. everything vaguely relevant except Windows), or on
OSs that have had a design improvement sometime this century. (I'm sure
dbus tries to support some that haven't.)

But this approach itself doesn't scale amazingly well. Because it aims
to be portable and have minimal dependencies, dbus contains its own
implementations of: a linked list; a hash table (adapted from Tcl, I
think); a portability layer to paper over the differences between Unix
and Windows, with varying success; a simple non-thread-safe main loop
(used by dbus-daemon) with pluggable backends for poll and epoll; a
memory-pool; main-loop integration glue for "full-fat" main loops like
GLib and Qt; UTF-8 validation; and so on and so forth. Because fewer
people have worked on it over a shorter timescale, none of these
features is actually as good as their equivalents in GLib[1] (and
because of some questionable licensing choices a decade or so ago, we
can't even just copy in GLib's implementations). I'm not a Qt or
Enlightenment expert, but their equivalents in QtCore and EFL are
probably way better too.

Because dbus is portable to Windows, AIX and other such horrors, the
main loop glue in particular has to have interesting contortions to work
around things like OSs with no poll(), OSs that can't aggregate a bunch
of fds and timeouts into one big meta-fd via modern designs like
timerfd/epoll, and so on.

Moving on to look at other libraries in the ecosystem around dbus, let's
look at Avahi. It has its own implementation of a linked list; a hash
table; a priority queue; several alternative (!) simple main loops;
main-loop integration glue for "full-fat" main loops like GLib and Qt;
UTF-8 validation; hey this is all looking remarkably familiar.

systemd? Linked list; hash table; main loop (although at least systemd
doesn't aim to be portable beyond Linux, so it can assume timerfd and
epoll); UTF-8; again, all rather familiar.

systemd's competitor, Upstart? Well there's a library called libnih,
that's clearly an excellent start. I haven't looked at it in detail but
I'm pretty sure it has all the same sorts of things in.

Let's try something a bit different: Cairo, a rendering library. Oh
look, there's the linked list. And the hash table. And some Unicode
support. At least I haven't seen a main loop yet.

libxml, perhaps? Linked list, check. Unicode, check. Their hash table is
called "dict", their I/O abstraction is 4k lines long and includes http
and ftp, and I don't immediately see a main loop but I wasn't looking
very hard.

I have to wonder, how many partial "make C not awful" libraries are
there on my Linux laptop, and how many copies of GLib could I fit in the
same amount of space they use? :-)

Hence my tendency to recommend "if you can, use GLib or similar; if you
think you can't, reconsider your constraints before proceeding" over
reinventing it for the nth time.

[1] possible exception: libdbus' linked list has some minor advantages
over GLib's.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
_______________________________________________
dbus mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dbus