Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Aug 2005 16:35:43 -0400 (EDT)
From:      Daniel Eischen <deischen@freebsd.org>
To:        Christophe Yayon <lists@nbux.com>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: nagios and freebsd threads issue : help please ...
Message-ID:  <Pine.GSO.4.43.0508191630140.12955-100000@sea.ntplx.net>
In-Reply-To: <43062603.5050206@nbux.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 19 Aug 2005, Christophe Yayon wrote:

> Hi all
>
> You should know about freebsd and nagios 2.0b threads issues (100% cpu
> use by a forked process, lost check result, some pause of nagios main
> process in certains obscursives conditions...).
>
> Some Nagios developpers says that the problem is in FreeBSD and some
> other says that the problem is in nagios pthreads implementation, here a
> resume of our discussions :
>    From
>
> http://www.opengroup.org/onlinepubs/009695399/functions/pthread_atfork.html
>
>   "It is suggested that programs that use fork() call an exec function
>   very soon afterwards in the child process, thus resetting all states. In
>   the meantime, only a short list of async-signal-safe library routines
>   are promised to be available."
>
>   Note *suggested*. This is a recommendation to protect against a shoddy
>   pthread-implementation. The thread specifications rule that only the
>   thread calling fork() is duplicated, which initially leads to the
>   recommendation (other threads holding locks aren't around to release
>   them in the new execution context).

They choose to quote a weak reference to the actual requirement.
The standard says (in the fork() section):

  A process shall be created with a single thread.  If a
  multi-threaded process calls fork(), the new process shall
  contain a replica of the calling thread and its entire address
  space, possibly including the states of mutexes and other
  resources.  Consequently, to avoid errors, the child process may
  only execute async-signal-safe operations until such time as one
  of the exec functions is called.  Fork handlers may be
  established by means of the pthread_atfork() function in order
  to maintain application invariants across fork() calls.

-- 
DE




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0508191630140.12955-100000>