Re: [TCLCORE] CFV: TIP #435

Am 03.08.15 um 18:53 schrieb Alexandre Ferrieux:
>     - call once and for all early in Tcl's init (like T_FE) > pthread_atfork(TclAtforkHandler)>     - let TclAtForkHandler be:>>           lock(&atfmutex);>           for(p=atflist;p;p=p->next) p();>           unlock(&atfmutex);>>      - of course a couple of convenience routine would allow to > add/remove callbacks to atflist any time, in a thread-safe way thanks > to atfmutex

the pthread_atfork() registers 3 functions (AtForkPrepare, AtForkParent, 
AtForkChild),
all of these make sense. Certainly, the callbacks can behave differently 
depending on
certain global variables (an execute registered functions etc.), but if 
one wants
to call arbitrary TclAPI-calls in these functions, one needs essentially 
a full lock of tcl

     Tcl_MutexLock(&notifierMutex);
     TclpMasterLock();
     TclpMutexLock();

One can't even call Tcl_MutexLock() safely in the registered callbacks 
without
the TclpMutexLock(). This was the reason i implemented a version of
tclUnixNotfy.c avoiding the Tcl_* interface at all (implementing locks
directly on the pthread_* interace, similar to the Mac OS X
variant tclMaxOSXNotfy.c). One reason for the need for the locks is
that the forked process is a copy of the parent with all its state,
including mutex variables, that might be already in the locked state.

The bad thing is that the longer the fork() takes (i.e. the larger
the memory footprint is, etc.), the longer we have a
full lock of the tcl-threads (time gap between AtForkPrepare() and 
AtForkChild()/
AtForkParent()). Therefore, not calling pthread_atfork() avoids this storm.

The other question is, why dos Tcl really need TclpMasterLock() and 
TclpMutexLock()
but that is another can of worms.

-g


------------------------------------------------------------------------------
_______________________________________________
Tcl-Core mailing list
Tcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core