Donald G Porter <dona...@nist.gov>:
>> 2) The new routine should only be called when the mutex argument>> is locked. How is it known in the AtForkChild() callback that>> this is the case?
On 05/20/2015 11:21 AM, Jan Nijtmans wrote:
> Because there's a Tcl_MutexLock/Tcl_MutexUnlock pair around> the pthread_atfork() call, that's where the AtForkChild() callback> is generated.
I may have a misunderstanding, but I thought that pthread_atfork()
registered the routines only; it did not call them. Rather they
get called as part of the whole fork() operation.
So when fork() is called, how do we know at that point that the
notifierMutex is locked by some thread?
>> Actually, if the new function is only called from inside Tcl core,> I wonder if we really should reserve a Stub entry for this.> This would mean that the bug can be solved without> the need for a TIP, in both 8.5 and 8.6 ;-)
An actual use case for making the routine public would improve
the proposal.
--
| Don Porter Applied and Computational Mathematics Division |
| dona...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Tcl-Core mailing list
Tcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core