[
https://issues.apache.org/jira/browse/MESOS-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604623#comment-13604623
]
Jie Yu commented on MESOS-394:
------------------------------
This link may help:
http://docs.oracle.com/cd/E19455-01/806-5257/gen-2/index.html
But I am not sure how to deal with those locks in glibc.
Another solution might be forcing the slave to be in single threaded mode
before fork, and resume the multithreaded mode after that.
> Don't do ExecutorLauncher in forked process but exec first instead.
> -------------------------------------------------------------------
>
> Key: MESOS-394
> URL: https://issues.apache.org/jira/browse/MESOS-394
> Project: Mesos
> Issue Type: Bug
> Reporter: Benjamin Hindman
>
> We've run into numerous issues where we've code executed in forked processes
> has deadlocked because resources (i.e., locks) from the parent process were
> not cleaned up (i.e., unlocked) in the forked process. Rather than continue
> this trend, we should always attempt to minimize the code executed in a
> forked process and if we're doing anything fancy do an exec right away. In
> particular, we should only be calling async-signal-safe functions in forked
> code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
