From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3148 Path: news.gmane.org!not-for-mail From: Rob Landley Newsgroups: gmane.linux.lib.musl.general Subject: Re: Best place to discuss other lightweight libraries? Date: Mon, 22 Apr 2013 19:31:03 -0500 Message-ID: <1366677063.18069.151@driftwood> References: <20130422215248.GR20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1366677080 11605 80.91.229.3 (23 Apr 2013 00:31:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Apr 2013 00:31:20 +0000 (UTC) Cc: musl@lists.openwall.com To: musl@lists.openwall.com Original-X-From: musl-return-3152-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 23 02:31:25 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UUR8m-0005J7-JL for gllmg-musl@plane.gmane.org; Tue, 23 Apr 2013 02:31:24 +0200 Original-Received: (qmail 23638 invoked by uid 550); 23 Apr 2013 00:31:23 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 23630 invoked from network); 23 Apr 2013 00:31:23 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:subject:to:cc:in-reply-to:x-mailer:message-id :mime-version:content-type:content-disposition :content-transfer-encoding:x-gm-message-state; bh=UWctwTsewdDqvAYhGepYpksxS4evZUs4SK09xnm16wo=; b=oNdBA0ptFjdznCkiNVFTpGtQnw1csTb/+9zEg2miN68ZbLJC2b0zywSxbprg5Du3K7 voeevwvyCtvbSVGmHOrRzBMgBb75vNQ4OZHsWnPGIFcBB+z2MxKzK/XxEIcSYdOUOVI3 gM/iGLQn0lLcPar1bamHL/jr3PIW0DT74ZjE30+1ij9bN0ZnqIXwGuuFQ58TFzRTrY4M cajCpZTN3xVXd36/+NlF1Oxf6lHmd8KnsmL1KN5kDnW9JQObKu7L+PNG9uoO1dTI5d8z xfsEpMO9cO1+cbGoO7I0iSuDn4+60vSuvDrocbl9hEyRq/zSacu/AKgs7B9wE/5vF30O U5qA== X-Received: by 10.50.51.200 with SMTP id m8mr9412117igo.52.1366677071426; Mon, 22 Apr 2013 17:31:11 -0700 (PDT) In-Reply-To: <20130422215248.GR20323@brightrain.aerifal.cx> (from dalias@aerifal.cx on Mon Apr 22 16:52:48 2013) X-Mailer: Balsa 2.4.11 Content-Disposition: inline X-Gm-Message-State: ALoCoQkhwx5Xl8MoQwmRPtlPzSJ8va6XUhdJv3jYkQb38W3TytL1s9JmkMxQ5ZQNcJIXojK28CmK Xref: news.gmane.org gmane.linux.lib.musl.general:3148 Archived-At: 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 =20 > 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 =20 layers that hide the details of what you're doing from _yourself_, and =20 which perform unnecessary work translating between your program and =20 itself. (Let's marshall data into structures! Let's copy it back out =20 again into _another_ structure! Let's do that five times in the same =20 darn call chain! Bonus points for passing a hardwired constant as the =20 only caller of a function that then checks that input for illegal =20 values!) It's nice to pull in a packaged solution that automates away fiddly =20 bits and tedium with tested and working code (which is basically what =20 libc is), but pulling in 8 megabytes of shared library to beep the =20 speaker instead of writing to a /proc file? Very common, and not an =20 improvement. (Random current example: why does qemu need an extended =20 attribute library to build the virtfs server? It doesn't pull in a =20 libchmod.so to set file ownership and permissions...) > > > - DBus. > > > > Sadly nobody is pushing for a better local socket multicast =20 > 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 =20 protocol.) > > I'm hoping for nanomsg once it is complete or Binder once it is > > correctly documented ^^; (and thus implemented in more than few =20 > forks of > > linux and maybe haiku) >=20 > 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 =20 require it? If it's easy to Not Do That, it should be possible to =20 demonstrate... > > > - Use of global state. Even seemingly-harmless things like a =20 > global > > > registered log function are harmful, because two different =20 > libraries > > > (or the main program and a library) might be trying to use the > > > library with the global log destination, and clobbering each =20 > other's > > > choices. > > > > For this there aren't solution that won't cause different problems =20 > I'm > > afraid. >=20 > 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: >=20 > http://misko.hevery.com/2008/11/21/clean-code-talks-global-state-and-sing= letons/ 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 =20 contexts between global and local. This is why objects were invented, =20 to provide a better syntax for contexts between global and local. But another issue is visibility of contexts. For example, if you put =20 stuff in environment variables, you can view and edit the environment =20 variables. So if you want it to stop doing something, or see whether or =20 not it's doing something, it's easy to dump state with any number of =20 tools. Unix had reasonable solutions for this stuff in the 1970's. Java =20 reinvented the wheel and thought "hexagonal" was a good idea, and it =20 _sort_ of works, and they've been filing bits off and gluing other bits =20 on ever since. (Alas, mostly they've just been making their wheel =20 _thicker_. Oh well.) Rob=