Re: Best place to discuss other lightweight libraries?

[Luca Barbato <lu_zero@gentoo.org>]

On 04/22/2013 04:53 PM, Rich Felker wrote:
> - Thread allergies, i.e. horribly over-complicating program logic to
>   avoid threads. The best examples I can think of are the added logic
>   needed to generalize a program that's reading from ordinary file
>   descriptors (e.g. connection sockets) in an event loop to support
>   SSL sockets or zlib-compressed streams. (Note: there are ways to
>   address this kind of problem more cleanly without threads too, but
>   nobody does it. I can elaborate if anybody's interested.)

I'm interested to read about it.

> - DBus.

Sadly nobody is pushing for a better local socket multicast abstraction
to send notifications back and forth in an efficient fashion.

I'm hoping for nanomsg once it is complete or Binder once it is
correctly documented ^^; (and thus implemented in more than few forks of
linux and maybe haiku)

> - Use of global state. Even seemingly-harmless things like a global
>   registered log function are harmful, because two different libraries
>   (or the main program and a library) might be trying to use the
>   library with the global log destination, and clobbering each other's
>   choices.

For this there aren't solution that won't cause different problems I'm
afraid.

> - Designs based on shared libraries, especially lots of them. This
>   creates bloat and often interferes with the ability to use static
>   linking.

Special mention to those that want to do clever stuff on the init
section (e.g. change a program global state from there)


> - Dependency on any library with the above problems. :-)

And that kills everybody using glib? *runs and hides*

lu