Re: [MACTCL] Execl

[Michael M. <mic...@na...>]

Daniel, thanks a lot for the responses.  I can see from your responses that
I'm out of my league here, so I'll come up with a plan B.


On 2006-05-27 00:43, "Daniel A. Steffen" <st...@ic...> wrote:

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