Re: [MACTCL] Execl

[Daniel A. S. <st...@ic...>]

On 27/05/2006, at 8:34, Daniel A. Steffen wrote:

> It appears that on Tiger you can do [package require Tk] from an  
> unthreaded tclsh in both parent and child of a [fork], c.f. example  
> (2), so that may be another way to get what you want if all your  
> subprograms are tk scripts; but AFAIR this didn't work on earlier  
> systems, see the list archive.
> Note that you need an unthreaded tcl due to a generic deadlock  
> issue with naked [fork] in threaded tcl on all platforms (missing  
> pthread_atfork handling).

of course I forgot that there is an issue even with unthreaded  
corefoundation tcl, because the CFRunLoop notifier implementation  
always uses a helper thread which does not survive fork. I have just  
committed a fix for this using a pthread_atfork handler to reinstall  
the notifier in the child after the fork:
	http://sourceforge.net/tracker/index.php? 
func=detail&aid=923072&group_id=10894&atid=310894
Note that pthread_atfork() is available starting with OS X 10.4 Tiger  
only, so tcl built on earlier releases will not include this fix.

Because vfork() is used by the core on OS X (since it always execve's  
after a fork), the atfork handler does not run for [exec] and [open  
|], i.e. core commands don't get any performance impact; the handler  
only gets called when an extension/embedder calls fork() directly,  
such as TclX's [fork].

On Tiger, this now makes [fork] safe to use from tcl with --disable- 
threads irrespective of corefoundation configuration option; but it  
doesn't fix the generic stale locked mutex issue with threaded tcl  
and fork discussed in the bug above, so threaded CF tcl can still  
deadlock in the child if any locks are held in the parent at the time  
of the [fork]...

Cheers,

Daniel

-- 
** Daniel A. Steffen        Dept. of Mathematics  **
** Macquarie University     NSW 2109 Australia    **