Re: [TCLCORE] CFV: TIP #435

On Mon, Aug 3, 2015 at 7:36 PM, Gustaf Neumann <neum...@wu.ac.at> wrote:

>> 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.>

OK, sorry for addressing only the superficial aspect (monotonic
pthread_atfork) rather than the deeper one (allowing "thick" and "thin"
forks from the same process).

In this context, I think the prime issue with pthread_atfork is that it is
process-wide, or thread-agnostic.
Hence, even if callback registration could be undone, juggling it in a
thread-safe way would still be a challenge.
So, what about instrumenting it to be thread-sensitive ? The idea is:

  - early:
pthread_atfork(ThreadAwareATF_Prepare,ThreadAwareATF_Parent,ThreadAwareATF_Child)

  /* these 3 handlers use pthread_self() as key into a *very* small
hashtable to decide what to do */


   - "thin fork": just call fork(). The above handlers find nothing for the
calling thread, and do nothing, quickly. The only temporarily lock a master
mutex protecting the hashtable.

   - "thick fork":
TclAtForkFromThisThread(AtForkPrepare,AtForkParent,AtForkChild) ; then
eventually call fork() (directly or not). This function stores an entry
into the hash table for pthread_self(), associating it with the 3 given
sub-callbacks, which are typically the Notifier-Cleanup machinery already
published by you and Joe.


With this:

  - very small overhead on [exec], since the registered atfork handler just
does a hashtable miss. No lock held between Prepare and Child. No linear
footprint dependency.

  - "thick fork" clients still have the complete expressivity of atfork
handlers.

-Alex

------------------------------------------------------------------------------