From owner-freebsd-questions@freebsd.org Mon Oct 2 09:03:54 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0BC4E3A2CE for ; Mon, 2 Oct 2017 09:03:54 +0000 (UTC) (envelope-from freebsd@erwanlegrand.com) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6922115D for ; Mon, 2 Oct 2017 09:03:54 +0000 (UTC) (envelope-from freebsd@erwanlegrand.com) X-Originating-IP: 74.125.83.43 Received: from mail-pg0-f43.google.com (mail-pg0-f43.google.com [74.125.83.43]) (Authenticated sender: moi@erwan.legrand.name) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 3B9591720EB for ; Mon, 2 Oct 2017 11:03:52 +0200 (CEST) Received: by mail-pg0-f43.google.com with SMTP id b1so1177356pge.1 for ; Mon, 02 Oct 2017 02:03:51 -0700 (PDT) X-Gm-Message-State: AHPjjUhTlw7pdgbwaV+v7bJyQUZvYgTDlLbADERNDebJQ4+d5UNWxfUo hKuJXLw/2pSQVLh9PigI17X/fYDB/lb/bwtEaUg= X-Google-Smtp-Source: AOwi7QD+HFQ1b1ulhbflvULszfAQBIzCsFusHQsHFSu2sy93esFi7U19Yyr0hhbiiGecBeytOYM/pQtz+6VYNMvJzm0= X-Received: by 10.159.244.9 with SMTP id x9mr13533641plr.34.1506935030485; Mon, 02 Oct 2017 02:03:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.155.10 with HTTP; Mon, 2 Oct 2017 02:03:49 -0700 (PDT) In-Reply-To: <20171002071000.GA1373@sh4-5.1blu.de> References: <20171002063425.GA21552@sh4-5.1blu.de> <102e950a-f3f2-bff1-1025-d5e757ee793b@gmx.com> <20171002071000.GA1373@sh4-5.1blu.de> From: Erwan Legrand Date: Mon, 2 Oct 2017 11:03:49 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: no dead-lock when signal handler calls localtime_r() on FreeBSD, but on Linux To: Matthias Apitz , FreeBSD Questions Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 09:03:54 -0000 On Mon, Oct 2, 2017 at 9:10 AM, Matthias Apitz wrote: > El d=C3=ADa Monday, October 02, 2017 a las 09:57:51AM +0300, Yuri Pankov = escribi=C3=B3: >> On Mon, 2 Oct 2017 08:34:26 +0200, Matthias Apitz wrote: >> >I'm on the way clarifying a deadlock-issue we face on Linux when localt= ime_r() >> >is called in a signal-handler funtion. If you compile the code attached >> >below with gcc on Linux, the code gives what one deserves: a dead-lock >> >when Ctrl-C is pressed. >> >> Why? I don't see anything explicitly stating that localtime_r() is >> async-signal-UNsafe. > > Because, as I said, it is not in the list of > > The following functions are either reentrant or not interruptible by > signals and are async-signal safe. Therefore applications may invok= e > them, without restriction, from signal-catching functions or from a = child > process after calling fork(2) in a multi-threaded process: > > in the man page sigactio(2). So what? Calling async-safe functions in signal handlers will not by itself trigger a bug. (Unless there is a bug in the implementation.) That is what a guarantee that async-safe functions (and standards) give. Assuming that calling in a signal handler functions which are not labeled as async-safe by some standard will reproducibility trigger a bug is faulty logic. Doing so *may* trigger a bug, but that is *not* a guaranteed behavior. localtime_r() is guaranteed to be thread-safe. It is not guaranteed to be async-safe. This suggest that the function might not be truly reentrant. It is only guaranteed to be reentrant with regard to thread safety. Async-safety requires reentrancy in a strictest sense. The implementation of localtime_r() in glibc is a good example as it calls a function named __tz_convert() which itself acquires a lock which makes it unsuitable for use within a signal handler. In the case of FreeBSD, a read-write lock is used and locatime_r() locks it as a reader. As multiple readers are allowed, this does not block in your case. Still, calling localtime_r() in a signal handler will block if the lock is acquired by a writer. Do not call async-unsafe functions in signal handlers. *Just don't!*