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.