DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 53AIb0Sa3400005
Authentication-Results:	delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results:	delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter:	OpenDKIM Filter v2.11.0 delorie.com 53AIb0Sa3400005
Authentication-Results:	delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=LFXuT8DQ
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 4A59C383602B
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1744310219;
	bh=/Q1jMN6yfis9TQ3yNxNLcew2lZXXAI9O3AOmkSp45sE=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	From;
	b=LFXuT8DQq4GYqd1u0mlxCmjfs8PC1tVdhqvsSMKwADFseO5HUcBxQJFhARmlAuxnB
	MxE8QfDAAXMRPYCEYQyfg5mTPEcdHAJCqSaC0sAJaiZVJQXFm/WbFAn+LCpc9M1fzo
	MN2ADScmcgDKrYIdZQO8r6YFkjYKdB99CRnKxI5Q=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 2A6523836EBF
Date:	Thu, 10 Apr 2025 20:35:49 +0200
To:	cygwin AT cygwin DOT com
Subject:	Re: pthread_atfork vs dlopen/dlclose
Message-ID:	<Z_gPhbc3c1iFX8Gz@calimero.vinschen.de>
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<07665688-8199-2e80-cdfe-abeaa6f56ba7 AT jdrake DOT com>
	<2021152719 DOT 99592 DOT 1744265074916 AT mail DOT yahoo DOT com>
	<b150c1e4-b3cd-4f90-8548-0c5f287948d4 AT jdrake DOT com>
	<94af5480-167a-fcc6-5f4c-89afa5ce8637 AT jdrake DOT com>
	<Z_eJqDJw-xbhktwC AT calimero DOT vinschen DOT de>
	<fe7d04eb-584d-ca1c-4408-be2bcd58e4af AT jdrake DOT com>
MIME-Version:	1.0
In-Reply-To:	<fe7d04eb-584d-ca1c-4408-be2bcd58e4af@jdrake.com>
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	cygwin AT cygwin DOT com
Cc:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
Errors-To:	cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

On Apr 10 11:03, Jeremy Drake via Cygwin wrote:
> On Thu, 10 Apr 2025, Corinna Vinschen via Cygwin wrote:
> 
> > > It seems glibc takes care of this implicit deregistration in
> > > __cxa_finalize, after calling __cxa_atexit functions, it unregisters any
> > > at_quick_exit or pthread_atfork callbacks from the DSO being unloaded.
> > >
> > > https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/cxa_finalize.c;h=2bb35602edc6bf842e5d2c93ad03454d7b57ee65;hb=HEAD
> > >
> > > It doesn't look like newlib deals with either at_quick_exit or
> > > pthread_atfork handlers in its __cxa_finalize implementation.
> >
> > Cygwin is doing this stuff mostly in its own code, see thread.cc.
> > It keeps lists of the callbacks in a global structure which is
> > called MT_INTERFACE throughout thread.cc.
> >
> > The functions pthread::atforkprepare(), pthread::atforkparent() and
> > pthread::atforkchild () are called from different spots during fork().
> >
> > Here's what we're missing:
> >
> > - Either keep track of the DLL a callback function is coming from by
> >   calling dlls.find (handle, true) and store the struct dll pointer.
> >   In dlclose(), if the DLL is of type DLL_LOAD or DLL_NATIVE, and
> >   the refcounter indicates that this is the last FreeLibrary, check the
> >   three callback lists in MT_INTERFACE and remove all functions
> >   with the same struct dll pointer.
> 
> I'm inclined to take this approach.

You can do the cleanup in dll_list::detach, btw.

> What about at_quick_exit though?
> That's entirely within newlib, isn't it?

Yes, and it's neither DSO aware, nor is it called during a normal exit.
I'd ignore it for now, or we need a new implementation along the lines
of the GLibc implementation which always stores the DSO handle together
with the handler function.  But that's something for 3.7, not a bugfix
for 3.6.


Corinna
> 
> -- 
> Problem reports:      https://cygwin.com/problems.html
> FAQ:                  https://cygwin.com/faq/
> Documentation:        https://cygwin.com/docs.html
> Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -