From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3746 invoked from network); 17 Jul 2020 21:28:39 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 17 Jul 2020 21:28:39 -0000 Received: (qmail 3358 invoked by uid 550); 17 Jul 2020 21:27:37 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 3340 invoked from network); 17 Jul 2020 21:27:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1595021245; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ksqqQe9jXGqBKXbmXaJ8uCMe7bkkI6uH58ROGtZU9B4=; b=Crrh3q3svQcGHgdlq8ws+0djc8IgBSniW6o8X+KFwFBV1I1ofvBjMxDxQTkFIxogpk/1ji nPaNTkT7rRaTMWuPtyc0D9fkhpPI7ojpJsaqL2xLy7QfneRvjgsuvOFVx7wehFxfI7OLmj dSBh6nmenffOs5zNNQd/dSgRYkckDRo= X-MC-Unique: cc5Llt8DPtaDsPWht2MkZA-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ksqqQe9jXGqBKXbmXaJ8uCMe7bkkI6uH58ROGtZU9B4=; b=WNZIrdn20RNILbc5pCKK1Qzs+u/GSaCkRy9U8O2i82qc1nvAJicv/v/qtuasAeDxZD WT9qXzW7NQ8xqEyl+K/nCYSXEd9WY0eELZ8O6wMx8VuJSPhBs7ujnnY8xc9y+U3/7i6m eVxJm2bQadCJhvFCtaNfjmV9gun3zf6bMDD4Bc7aS7PvhjxXlQKKQr3crneEqDuvyhCw 8Jrh5F/KwbXS4q0ytMetxRrkc8AwxxMg7x7U0pI2XB5wtNWEqJFJUNKiuQR4sa3Be3jx 7oLBNbBJ1EHkT1FEpp25e4hraoxj61nfHoRZvEZdYszYN1KoIM+1VTCS7+jtznD2+dHn +Rgw== X-Gm-Message-State: AOAM530YgLvwaU45HuGybo88qzAJ2tfl1mZ/M8ErI8R3n7Rq99lP1BKC Iq9YaUqzl97BPXkdunkxSwOq/etGCX+5n5wfp1NPih6Y/Bm6D+7XrLzulz6KK18C+LyCAl6dwwQ aVjNaxWNVUR7WdpA0cQ== X-Received: by 2002:a05:6214:1926:: with SMTP id es6mr10997742qvb.222.1595021239351; Fri, 17 Jul 2020 14:27:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxbPMw9/J0UU4wkJWiCHACoHNSTmKSSyYMjb2hQdkdtzCwIWTQ9mflVQY9N0IN4CFFRZbrgzQ== X-Received: by 2002:a05:6214:1926:: with SMTP id es6mr10997723qvb.222.1595021239059; Fri, 17 Jul 2020 14:27:19 -0700 (PDT) To: musl@lists.openwall.com, Rich Felker , Hydro Flask , Florian Weimer References: <04c05d65470b5c94808481eaf724cc5d@yqxmail.com> <87pn8uwu18.fsf@oldenburg2.str.redhat.com> <4095a8a7f75becee9bcfc71024e43802@yqxmail.com> <20200717092111.GA3210874@port70.net> <7a8de0d4-d9f7-6ab2-1aec-713597b47ca8@redhat.com> <03e28c2e6beb406c3a1ce3bfa99c67eb@yqxmail.com> <20200717211050.GB3210874@port70.net> <20200717211933.GI14669@brightrain.aerifal.cx> From: Carlos O'Donell Organization: Red Hat Message-ID: <95e258a1-e376-1d2f-2533-f100b37b1e7b@redhat.com> Date: Fri, 17 Jul 2020 17:27:17 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200717211933.GI14669@brightrain.aerifal.cx> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [musl] Idea: futex() system call entry point On 7/17/20 5:19 PM, Rich Felker wrote: > On Fri, Jul 17, 2020 at 11:10:50PM +0200, Szabolcs Nagy wrote: >> * Hydro Flask [2020-07-17 11:57:36 -0700]: >>> On 2020-07-17 07:43, Carlos O'Donell wrote: >>>> On 7/17/20 5:21 AM, Szabolcs Nagy wrote: >>>>> * Hydro Flask [2020-07-16 23:29:53 -0700]: >>>>>> On 2020-07-16 23:10, Florian Weimer wrote: >>>>>>> * Hydro Flask: >>>>>>> >>>>>>>> I have a project that implements an API that must be AS-safe. >>>>>>> >>>>>>>> Had the idea of using futex() but my other constraint is that the >>>>>>>> blocking call must also be a cancellation point. >>>>>>> >>>>>>> Cancellation points in signal handlers lead to asynchronous >>>>>>> cancellation. Are you sure that this is what you want? >>>>>> >>>>>> Yes I am aware of that. The caller is responsible for making >>>>>> sure it is safe >>>>>> to call the cancellation point in the signal handler per the >>>>>> recommendations >>>>>> in POSIX. >>>>> >>>>> how does the caller ensure that the interrupted >>>>> code is async cancel safe? >>>> >>>> I would also like to know that :-) >>>> >>>> Requiring AC-safety in the interrupted code is going >>>> to seriously limit what that code can call and do >>>> and indirectly what compiler and language implementation >>>> can even be used to implement that compiled code. >>> >>> There is a section in POSIX that covers exactly this, read the "Application >>> Usage" section of https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_setcancelstate.html >>> >>> In general the user should ensure that cancellation is disabled one way or >>> another when the call is called from the signal handler, or that the call is >>> being done in a AC-safe region. There are a variety of ways to do this as >>> discussed in POSIX. >> >> it's possible to do this, but it's a rare requirement. >> >> futex is not a nice syscall to expose in c. >> >> currently there is disagreement about how to expose it: >> directly the linux api (which is variadic and not very >> typesafe) or separate calls for the useful operations >> (futex_wait, futex_wake, etc but the exact c api is >> less clear then). >> >> because of new time_t abi on 32bit targets, the timeout >> argument to futex is another reason to expose it in c >> instead of allowing users to use it via syscall (if they >> use the libc timespec type with the raw syscall that can >> be broken). >> >> in any case it's better to discuss this on libc-alpha >> since musl and glibc must expose the same api for it >> to be useful and it is harder to get this into glibc. > > CC'ing libc-coord would also be appropriate for this, I think, even if > it is Linux-only and not relevant to the BSD etc folks there. > > I do want to expose futex function but I don't want to end up with > something gratuitously incompatible/conflicting with what glibc ends > up doing. Likewise. -- Cheers, Carlos.