On Thu, 2 Mar 2017 13:32:23 -0800, Jun Wu wrote: > Excerpts from Yuya Nishihara's message of 2017-03-03 00:51:12 +0900: > > I hope so, but googling "fork thread" or "fork thread python" made me feel > > bad. I haven't read them carefully, but they seemed to say "don't do it." > > Good catch! > > I had a look at CPython source code. The most related function is > PyOS_AfterFork(void), which will be executed by the child. It does not > handle all lock issues (like malloc() in libc). > > I think we can use os.fork() in master and avoid threading to solve the > issue: > > worker master forked master > | send(repopath) -> | > | fork() -----> | > | preload() > | replace master's socket > | connect() ----------------------> | > > This solves other problems - like parsers.c has some slow functions that may > block accept().
Hmm, that seems relatively simple and worth trying. We might have to rewind stack before fork() so the forked master wouldn't end up exhausting Python stack. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
