Comment 15 for bug 1672819

On 8 May 2017 at 10:32, Colin Ian King <email address hidden> wrote:

> exec'ing from a thread is an interesting problem; the semantics of exec
> should be to terminal all the threads before the exec occurs according
> to http://maxim.int.ru/bookshelf/PthreadsProgram/htm/r_44.html
>
> The normal idiom would be to do:
> fork()
> child exec's
> parent waits for child
>
> I'm not sure in your case if you desire all the threads to terminate
> after the exec, so the wait() may be in fact be replaced by pthread
> termination calls on all the threads for your implementation.
>

The original bug report was about a process calling execve directly, not a
fork/exec situation. So yes, the expectation is that all threads are gone.

> Unfortunately there is an issue with fork'ing in a thread; any mutex
> held by another thread at the moment of fork becomes locked forever
> since we have once mutex locked by the parent and one by the child.
> Normally one would therefore use pthread_atfork() to help workaround
> this issue, see https://stackoverflow.com/questions/14407544/mixing-
> threads-fork-and-mutexes-what-should-i-watch-out-for

Go doesn't support forking (except for some very careful code that calls
exec in the child), for exactly this sort of reason.