From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9499 Path: news.gmane.org!not-for-mail From: Pedro Giffuni Newsgroups: gmane.linux.lib.musl.general Subject: Re: FreeBSD's Google Summer of Code 2016 Date: Sat, 5 Mar 2016 20:11:20 -0500 Message-ID: <56DB83B8.10500@FreeBSD.org> References: <56DB3D70.8010601@FreeBSD.org> <20160305212517.GK9349@brightrain.aerifal.cx> <56DB6095.4060204@FreeBSD.org> <20160305233254.GL9349@brightrain.aerifal.cx> <56DB766A.3050500@FreeBSD.org> <20160306002547.GM9349@brightrain.aerifal.cx> <20160306003107.GN9349@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1457226653 19507 80.91.229.3 (6 Mar 2016 01:10:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 6 Mar 2016 01:10:53 +0000 (UTC) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-9512-gllmg-musl=m.gmane.org@lists.openwall.com Sun Mar 06 02:10:47 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1acNDb-0004v9-2y for gllmg-musl@m.gmane.org; Sun, 06 Mar 2016 02:10:47 +0100 Original-Received: (qmail 15581 invoked by uid 550); 6 Mar 2016 01:10:44 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 15560 invoked from network); 6 Mar 2016 01:10:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1457226632; bh=lODYBKKJnJbEWU3R6i11hWSQWeTJwDVPAW6s+PqSPzU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=eu5JsAiRy2NGLBTQpwyUKfbYBZ7noUMTZKwj7MDHxqaNuu0wdsGxU1+x0gVNcETmwFmCyhR1ifrYXMcXPx0o7M7qfYQuWJImMUOf/f+MScOowFjusCcM8UTO341yl3vf9eYztPUV+7ghFhfUx00sB2URSFf5tCESOqBqtDZ9+eDG0kj6UnIaxkU6/KswlKNAgkS2X5gOOoeLd7nL1JV+58+fahIsFmsRTa7yfiRaPvV8m33UDvo2glw7VcUA0JV1Iw1FV2fqZei3s9PDLydBNIeJUXSbJkbvF/DvZxOGrSdUBhP6zG7KfRYZP+r6mYZSOjgIw4mKIKk0c8odEZLvfA== X-Yahoo-Newman-Id: 922593.6671.bm@smtp232.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: o5f3PnsVM1lKoIOKW8xywEF7rdD3vASDgCIU06RCqwAJNTI w_hJKcnuyaxNuEUJ1aePT6PGxxZ7qKKvenCU8MkrbqqzaK_Z2S5NbsZ.yOgf AnVCoTQE0jPQZMG_2B1.vfxUrdZS5SLRyqYjtyFFOmUByDWlTuzo7jwS9y8V ca7G1mo6M9ww6QNT1sZOF.T7O3dgbnLKdt2dC0HD0AnAJI5DWfUJMXTHOcBl nAyDv6HOCCb4wQr_7O0km6l3tJmFtWxqtGk6Oi6lDbxs8t49vCqdsxnsk1LV Y5WppYi80CVCRKDp7m8xVJ403yh5s7p4KIcHDyEoi86kzG1_817xf8O_tJAP biSyXWk4PYklIokJ5diweBfRoiV51YlyfR_fJslje5LmjwAGdksZYoF02FyC xvWDO3qT22TCuG6mEh.Y9clhoaxOrSjrq.hiItjru8_K1LKMsQ2oEl97pg_d FERathhXjXZYgmiesw_N7KSr3U9oGIt215hrjMbGvwEtd8twiYlN3RaUf1VY tJpw50o7ZyUJi2B0vT.qqnbcMzKt0qeSs X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 In-Reply-To: <20160306003107.GN9349@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:9499 Archived-At: On 03/05/16 19:31, Rich Felker wrote: > On Sat, Mar 05, 2016 at 07:25:47PM -0500, Rich Felker wrote: >> On Sat, Mar 05, 2016 at 07:14:34PM -0500, Pedro Giffuni wrote: >>> >>> >>> On 03/05/16 18:32, Rich Felker wrote: >>>> On Sat, Mar 05, 2016 at 05:41:25PM -0500, Pedro Giffuni wrote: >>>>> First of all, great to hear there is interest on the musl side too. >>>>> >>>>> I think the biggest precedent of porting linux-oriented C libraries >>>>> came from Debian's kFreeBSD. We accomodated a little by for them >>>>> by defining __FreeBSD_kernel__ in sys/param.h. >>>>> >>>>> While using the optional linux-abi futex in FreeBSD could be an option, >>>>> it is not really the cleanest option. The Debian guys did a port of >>>>> NPTL using regular pthreads: >>>>> >>> >>> Of course I ahould have meant "based on regular FreeBSD kernel services". >>> >>>>> http://thread.gmane.org/gmane.linux.debian.ports.bsd/11702 >>>>> >>>>> I am certain this will require more research but it would be useful >>>>> for other ports as well. >>>> >>> >>> We could ask Petr Salinger for the details, but I am pretty sure >>> FreeBSD has the required functionality natively. >>> >>>> Glibc/NPTL has a lot of what I'd call "gratuitous abstraction" (like >>>> the lll stuff) in their pthread primitives which makes this >>>> "possible". I call it gratuitous because it's really really hard to >>>> achieve correct implementations of the pthread sync primitives that >>>> don't have serious corner-case bugs, and it's unlikely that their >>>> abstractions actually suffice to make correct alternate >>>> implementations. >>>> >>>> musl does not have any such abstraction. We require a compare-and-swap >>>> operation or equivalent on which arbitrary atomic operations can be >>>> constructed, a futex or equivalent operation that's roughly >>>> while(*addr==expected) sleep(), and implement all the sync primitives >>>> just once on top of these. >>>> >>> >>> I am not a threading expert (or even a CS guy), but it sounds like >>> mutex(9) with condvar(9) would do [1]: >> >> No, they don't satisfy the needs of musl; they have their own >> additional storage requirements and are probably not AS-safe. It might >> be possible to use them to implement a userspace-emulated futex queue >> (only if they are AS-safe), but I don't see a way to extend that to >> the process-shared case. > > Actually these look like kernelspace APIs, not userspace, unless I'm > mistaken. In that case I don't see how they're relevant/usable. Is tht > correct? > Ugh .. yeah ... sem(9) is kernel only API too. The best is to look at the native thread library, not precisely the easiest to read code in the world, I'm afraid. OpenGrok may help: http://src.illumos.org/source/xref/freebsd-head/lib/libthr/ Pedro.