From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96664 invoked by alias); 13 Dec 2017 23:35:46 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 96654 invoked by uid 89); 13 Dec 2017 23:35:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=glance, suited, skills, commentary X-HELO: mail-qt0-f174.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=o1TPY4K4babwoGgBCP3r7NWxgKfqlaajezg8EZKAFjQ=; b=RKMHoOQtSK1skuE+x79oJlVUOS50XW0xyXytyz/8UW2qRqEio0NeYhBJgnpCnMIpLr f7Dt3SHyZ3sJnbp8FNqQ1ueSaPQnI/ojE2cm4mAYkekLVHlszTkn4tMmpaqhc0xU4bma wq0OBr94q6Ek+u2JfjZZJICTleYlax5+xIPip/nzXu+/jmDPOFz1iO9myO330HQOf7jS m92n5nWfOVvPyBcpUehoFYT05fdeqWqehhiVE7qyciUTbGTS3ILvjoI30jPKUXLLomrU ATNrCatw6VrjbOTOp1FfL3jit0+cRpW3xmpxhm0yt2sFLgJbRXmL3/nBcYaYTcF9lvf9 PsOA== X-Gm-Message-State: AKGB3mLHoyjCBTAYy1qsdh6Fp9p/SIlFjor0LAyQo0Xc+Jx18x7vDe86 1HTmZErkZAeULXwDk3Y8Sewp7Fo71f9OTsuanMxP6Q== X-Google-Smtp-Source: ACJfBovOfTdAxf0D4SmyV+FxZV8zLQH7CRDakWwhCJkuitMv+eU8zH6LhriGsFfW7tLPAiaDWvm2T2rYaabg5HV0rco= X-Received: by 10.200.26.123 with SMTP id q56mr14147420qtk.145.1513208142599; Wed, 13 Dec 2017 15:35:42 -0800 (PST) MIME-Version: 1.0 From: Oleh Derevenko Date: Wed, 13 Dec 2017 23:35:00 -0000 Message-ID: Subject: [RFC 0/1] Contributing a compound object to the libpthread To: "Carlos O'Donell" Cc: libc-alpha@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2017-12/txt/msg00420.txt.bz2 Hi Carlos, On Wed, Jan 13, 2016 at 5:55 AM, Carlos O'Donell wrote: > > On 01/06/2016 06:38 AM, Oleh Derevenko wrote: > > Hi All, > > > > Sorry for a somewhat unusual question. > > > > I have a devised a compound synchronization object approximately of > > the rwlock's level which helps with some aspects of data queue > > handling and provider-consumer interactions between threads. One of > > particular uses - it allows to wait for a worker to complete a > > specific work item with priority inheritance from the waiting thread > > (if the OS provides the priority inheritance feature at all, of > > course). If I would like to contribute this object to the libpthread, > > what would be the best way/place to do it? > > At present libpthread implements the POSIX Threads functions and some > additional non-portable extenions. We don't deviate much from pthreads. > If your new feature is quite different then it might not be a match for > libpthread or glibc. > > You should start by making your code available perhaps in a distinct > project or as a glibc add-on and discussing further once you have more > concrete information to present. Consider carefully the license of your > code and all things you'll need for a good contribution: > https://sourceware.org/glibc/wiki/Contribution%20checklist > > I know it's quite a lot to review, but license and copyright assignment > are the top two things to get out of the way if you're looking to > contribute to the project at any level. > > We are also starting to discuss a non-pthread experimental library > for exposing executaion agent interfaces to be used by higher level > frameworks whose requirements don't directly map well onto POSIX > threads. Your synchronization object might be suited to such an > experimental library, but again it's hard to say without any more > information. > > Cheers, > Carlos. > Sorry for a kind of necroposting -- it has been quite long since I started this topic. So, having considered what I had, I decided to apply for a patent on the synchronization technique I mentioned. After all, it's not every day you come up with ideas like that. Now the application has been published and is available at http://appft.uspto.gov/netahtml/PTO/search-adv.html (use =E2=80=9CDN/20170329652=E2=80=9D for the search) and thus I can present the= related implementation here, following in the next e-mail fragment. The functions and the synchronization objects themselves were formatted in the style and with naming conventions of libpthread (merely for sake of convenience). There are descriptive commentaries in the code and a few usage examples written as C pseudocode in a commentary at the end of the header file. I could provide these objects free for GPL licensed projects (and probably for LGPL applications as well -- all, but libraries, to avoid misuse within commercial sotware), if the public is interested in it. I'm not generally following the discussions here but throwing a quick glance now and then I saw people trying to get priority inheritance with pthread_cond_wait(). My synchronization objects are a readily available alternative. And though requiring somewhat advanced synchronization skills and proper thread hierarchy design, they cover all my needs for event waits requiring priority inheritance. --=20 Oleh Derevenko -- Skype with underscore