Date: Mon, 22 Aug 2005 09:46:04 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: deischen@freebsd.org Cc: freebsd-hackers@freebsd.org, lists@nbux.com Subject: Re: nagios and freebsd threads issue : help please ... Message-ID: <20050822.094604.112623156.imp@bsdimp.com> In-Reply-To: <Pine.GSO.4.43.0508221130550.28532-100000@sea.ntplx.net> References: <20050822.080938.95905450.imp@bsdimp.com> <Pine.GSO.4.43.0508221130550.28532-100000@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <Pine.GSO.4.43.0508221130550.28532-100000@sea.ntplx.net>
Daniel Eischen <deischen@freebsd.org> writes:
: On Mon, 22 Aug 2005, M. Warner Losh wrote:
:
: > So there's something in the list, I've gone through and done a call
: > tree analysis to show the extensive and pervastive nature of the
: > functions that nagios calls after fork. I don't know if these are all
: > problems or not, since I don't know if some of these functions might
: > be called before the first thread is created with pthread_create.
: > However, any that are called after that clearly have undefined
: > behavior.
:
: Note that we (David Xu and myself) took a different approach
: to handling fork() in libpthread (and probably libthr) than
: was done in libc_r. We thought it better not to try and
: reinitialize libpthread (and to some extent libc) because
: it is messy and to expose non-portable applications.
Is there some way to flip a switch and get an abort in all the
non-async-safe-safe functions in libc :-)
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050822.094604.112623156.imp>