[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Implement open-process and related functions on MinGW

From: Eli Zaretskii
Subject: Re: [PATCH] Implement open-process and related functions on MinGW
Date: Sun, 23 Feb 2014 19:46:19 +0200

> From: Mark H Weaver <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Sat, 22 Feb 2014 23:40:20 -0500
> Eli Zaretskii <address@hidden> writes:
> >> It's safe to fork a multithreaded program without using pthread_atfork
> >> if only async-signal-safe functions are called before the exec.
> >
> > You may know what your code does between fork and exec, but you don't
> > know what other parts do, like pthreads or the application that called
> > Guile as a library.
> I'm not sure I understand what you mean here.  The relevant code here is
> between line 1366 (/* The child.  */) and the call to execvp on line
> 1408.  I see calls to 'close', 'open', 'dup', and 'dup2'.
> How could "pthreads" or "the application that called Guile" cause
> anything else to happen between fork and exec in the new single-thread
> child process?

Pthreads could have locked some mutex before you fork, for example, in
which case the child starts with a locked mutex and no live thread
that will release it any time soon.  The application could have done
similar things, especially if it also uses threads, or some library
that uses shared memory.

Btw, I didn't write above anything that is not described here:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]