From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44449 invoked by alias); 19 Oct 2017 03:12:22 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 44421 invoked by uid 89); 19 Oct 2017 03:12:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Great X-HELO: brevard.conman.org Received: from brevard.conman.org (HELO brevard.conman.org) (66.252.224.242) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Oct 2017 03:12:17 +0000 Received: by brevard.conman.org (Postfix, from userid 500) id 512DC2EA6406; Wed, 18 Oct 2017 23:12:16 -0400 (EDT) Date: Thu, 19 Oct 2017 03:12:00 -0000 From: Sean Conner To: libc-help@sourceware.org Subject: Re: determine whether code is running in a signal handler context Message-ID: <20171019031216.GB19581@brevard.conman.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg00020.txt.bz2 It was thus said that the Great Yubin Ruan once stated: > Hi, > > I am writing to see if this is any util functions in libc that can > help to determine it is currently running in a signal. > > I wrote some library and provide a function which will be used in many > client code. However this function is not async-signal safe (it calls > malloc(3)) so when it is called, I want to detect whether it is > currently running in a signal handler. If it is, I can avoid calling > those not-async-signal-safe functions which might cause deadlock. Wouldn't it be easier (and safer) just to document the library as not-async-signal-safe ("These functions, called from a signal handler, will invoke undefined behavior")? Use a large font if you have to, but I think protecting programmers from themselves over the long term is bad. -spc