On 8 May 2017 at 10:32, Colin Ian King <[email protected]> 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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1672819/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
