[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1366677063.18069.151@driftwood>
Date: Mon, 22 Apr 2013 19:31:03 -0500
From: Rob Landley <rob@...dley.net>
To: musl@...ts.openwall.com
Cc: musl@...ts.openwall.com
Subject: Re: Best place to discuss other lightweight libraries?
On 04/22/2013 04:52:48 PM, Rich Felker wrote:
> On Mon, Apr 22, 2013 at 05:21:25PM +0200, Luca Barbato wrote:
> > On 04/22/2013 04:53 PM, Rich Felker wrote:
> > > - Thread allergies, i.e. horribly over-complicating program logic
> to
...
> zlib, etc.). Then, your main event loop just sees a normal file
> descriptor, so you don't have to invade your code that handles
> streams/connections/whatever with a new abstraction framework around
> file descriptors that also supports SSL or whatever. Not only are such
> abstraction layers bloated; they also add a lot of places for bugs to
...
> possible (e.g. a webserver). But for something like an IRC client or
> web browser, where socket performance is irrelevant compared to other
> things, it's idiotic to design fancy abstraction layers for reading
> and writing to connections when you could just do a design like what I
> described above.
If I might suggest: the general problem is unnecessary abstraction
layers that hide the details of what you're doing from _yourself_, and
which perform unnecessary work translating between your program and
itself. (Let's marshall data into structures! Let's copy it back out
again into _another_ structure! Let's do that five times in the same
darn call chain! Bonus points for passing a hardwired constant as the
only caller of a function that then checks that input for illegal
values!)
It's nice to pull in a packaged solution that automates away fiddly
bits and tedium with tested and working code (which is basically what
libc is), but pulling in 8 megabytes of shared library to beep the
speaker instead of writing to a /proc file? Very common, and not an
improvement. (Random current example: why does qemu need an extended
attribute library to build the virtfs server? It doesn't pull in a
libchmod.so to set file ownership and permissions...)
> > > - DBus.
> >
> > Sadly nobody is pushing for a better local socket multicast
> abstraction
> > to send notifications back and forth in an efficient fashion.
When I say that it always winds up being my job. (Belling the cat
protocol.)
> > 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)
>
> Yes, Binder looks really promising, but I also think part of the
> problem is that the need for this kind of interface is exaggerated...
Is anybody collecting patches to remove it from packages that currently
require it? If it's easy to Not Do That, it should be possible to
demonstrate...
> > > - 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.
>
> Sure there are. I get the impression you can tell I was talking about
> libav/ffmpeg's log interface. :-) The obvious solution is to bind log
> contexts to the object you're acting on. See this nice talk:
>
> http://misko.hevery.com/2008/11/21/clean-code-talks-global-state-and-singletons/
Was that the java one?
> If I remember right, part of the problem way back was that there were
> deep function calls that had no context available to them, and that
> didn't _need_ a context for anything but logging warnings or whatnot.
> Really, the fact that they can fail and want to be able to report
> failure means they _do_ need a context, but I can understand the
> desire to cheat, especially if there's a performance cost to passing
> the context all the way down. In that case, hidden non-global state,
> namely thread-local storage, might be an appropriate solution. It's
> still hidden state (and thus A Bad Thing), but at least it's no longer
> global state.
There are contexts between global and local. There have always been
contexts between global and local. This is why objects were invented,
to provide a better syntax for contexts between global and local.
But another issue is visibility of contexts. For example, if you put
stuff in environment variables, you can view and edit the environment
variables. So if you want it to stop doing something, or see whether or
not it's doing something, it's easy to dump state with any number of
tools.
Unix had reasonable solutions for this stuff in the 1970's. Java
reinvented the wheel and thought "hexagonal" was a good idea, and it
_sort_ of works, and they've been filing bits off and gluing other bits
on ever since. (Alas, mostly they've just been making their wheel
_thicker_. Oh well.)
Rob
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
