On Wed, 22 Jun 2005, I wrote:
> Daniel Eischen wrote:
> > On Tue, 21 Jun 2005, Michal Mertl wrote:
> >
> > > Dag-Erling Smrgrav wrote:
> > > > Charles Sprickman <[EMAIL PROTECTED]> writes:
> > > > > 1. FreeBSD and threads. On FreeBSD there's a native user-level
> > > > > implementation of threads
On Thu, 23 Jun 2005, Kamal R. Prasad wrote:
>
> --- Daniel Eischen <[EMAIL PROTECTED]> wrote:
>
> > (all?) of which
> > > will be async-signal-safe anyway). Simple example:
> > any lock that the
> > > libc implementation needs to provide its
> > functionality may be
> > > arbitrarily locked by some
--- Daniel Eischen <[EMAIL PROTECTED]> wrote:
> On Wed, 22 Jun 2005, Peter Edwards wrote:
>
> > On 6/22/05, Kamal R. Prasad <[EMAIL PROTECTED]>
> wrote:
> > >
> > > The child process should be able to call any
> system
> > > calls it likes -without assuming that pthreads
> from
> > > the parent
On Wed, 22 Jun 2005, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Daniel Eischen <[EMAIL PROTECTED]> writes:
> : We do protect the malloc lock across a fork(), but that's it.
>
> With 4.x libc_r, you could easily get hangs accross a fork() if you
> did anything before the
In message: <[EMAIL PROTECTED]>
Daniel Eischen <[EMAIL PROTECTED]> writes:
: We do protect the malloc lock across a fork(), but that's it.
With 4.x libc_r, you could easily get hangs accross a fork() if you
did anything before the exec (like setup fd's for stdin/out). This
was due to
On Wed, 22 Jun 2005, Luigi Rizzo wrote:
> reading also the continuation of this mail thread, I wonder if there
> is any relationship with this issue i found a few days ago debugging
> asterisk. It happens when linking the code with libc_r, but maybe
> some of the bugs in libc_r were also imported
Daniel Eischen wrote:
> On Tue, 21 Jun 2005, Michal Mertl wrote:
>
> > Dag-Erling Smrgrav wrote:
> > > Charles Sprickman <[EMAIL PROTECTED]> writes:
> > > > 1. FreeBSD and threads. On FreeBSD there's a native user-level
> > > > implementation of threads called 'pthread' and there's also an
> > > >
reading also the continuation of this mail thread, I wonder if there
is any relationship with this issue i found a few days ago debugging
asterisk. It happens when linking the code with libc_r, but maybe
some of the bugs in libc_r were also imported in other thread
libraries.
cheers
On Wed, 22 Jun 2005, Peter Edwards wrote:
> On 6/22/05, Kamal R. Prasad <[EMAIL PROTECTED]> wrote:
> >
> > The child process should be able to call any system
> > calls it likes -without assuming that pthreads from
> > the parent process have been copied over to the child
> > process. I spose most
On Wed, 22 Jun 2005, Norbert Koch wrote:
> > [snip]
> > > at least some assumptions that the child won't be
> > > doing much before
> > > execing or exiting. (But Im sure one of the
> >
> > The child process should be able to call any system
> > calls it likes -without assuming that pthreads from
On 6/22/05, Kamal R. Prasad <[EMAIL PROTECTED]> wrote:
> [snip]
> > at least some assumptions that the child won't be
> > doing much before
> > execing or exiting. (But Im sure one of the
>
> The child process should be able to call any system
> calls it likes -without assuming that pthreads from
> [snip]
> > at least some assumptions that the child won't be
> > doing much before
> > execing or exiting. (But Im sure one of the
>
> The child process should be able to call any system
> calls it likes -without assuming that pthreads from
> the parent process have been copied over to the chil
[snip]
> at least some assumptions that the child won't be
> doing much before
> execing or exiting. (But Im sure one of the
The child process should be able to call any system
calls it likes -without assuming that pthreads from
the parent process have been copied over to the child
process. I spo
On 6/20/05, Charles Sprickman <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Just curious if there's any regulars here who would like to help Ethan
> out:
>
[snip]
>
> ... It happens when the main thread forks to execute an active
> check. On the second fork to create the grandchild, the grandchild is
On Tue, 21 Jun 2005, Michal Mertl wrote:
> Dag-Erling Sm?rgrav wrote:
> > Charles Sprickman <[EMAIL PROTECTED]> writes:
> > > 1. FreeBSD and threads. On FreeBSD there's a native user-level
> > > implementation of threads called 'pthread' and there's also an
> > > optional ports collection 'linuxth
Michal Mertl <[EMAIL PROTECTED]> writes:
> Yes, the description on Nagios page is not precise but unfortunately
> Nagios still has some problems even on 5.4. I wasn't able to find out
> what was wrong and the problem dissappeared when I had to replace the
> computer with single-processor one. The s
Dag-Erling Smørgrav wrote:
> Charles Sprickman <[EMAIL PROTECTED]> writes:
> > 1. FreeBSD and threads. On FreeBSD there's a native user-level
> > implementation of threads called 'pthread' and there's also an
> > optional ports collection 'linuxthreads' that uses kernel hooks.
>
> This is only the
Charles Sprickman <[EMAIL PROTECTED]> writes:
> 1. FreeBSD and threads. On FreeBSD there's a native user-level
> implementation of threads called 'pthread' and there's also an
> optional ports collection 'linuxthreads' that uses kernel hooks.
This is only the case for FreeBSD 4. FreeBSD 5 has nat
18 matches
Mail list logo
