Date: Tue, 22 Jun 2004 17:50:34 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Dan Nelson <dnelson@allantgroup.com> Cc: Chris Stenton <jacs@gnome.co.uk> Subject: Re: pthread - fork - execv problem Message-ID: <Pine.GSO.4.10.10406221745060.4146-100000@pcnet5.pcnet.com> In-Reply-To: <20040622210820.GA17392@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 22 Jun 2004, Dan Nelson wrote: > In the last episode (Jun 22), Daniel Eischen said: > > > libpthread in -current does support pthread_atfork, and I have a > > > patch (below) that adds the same functionality to libc_r and libthr > > > that I need to send-pr. Pointy hat to the original committer for > > > breaking ABI compatibility. http://dan.allantgroup.com/FreeBSD/ > > > > Whaa? Adding a function doesn't break ABI, and I don't want to > > maintain 3 thread libraries. > > It does if an application detects pthread_fork during configure and > uses it. You then can't use libmap to redirect libpthread to one of > the other thread libraries for testing, since you'll get an undefined > symbol error at runtime. Bah. libc_r is marked for deprecation and libpthread is the default library in -current. > Nikos Ntarmos also noticed that there's no pthread_atfork manpage. We > could probably just use the Single Unix one. Yes, you can now that The Open Group have given us permission :-) -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10406221745060.4146-100000>