[GRASS-dev] forking on OSX Leopard (or earlier for that matter)

William Kyngesburye woklist at kyngchaos.com
Sun Mar 30 12:28:36 EDT 2008

A change in OSX Leopard (10.5) that may affect GRASS, though I haven't  
seen any problems yet.  From a release note for the developer tools:

CoreFoundation and fork()
Due to the behavior of fork(), CoreFoundation cannot be used on the  
child-side of fork(). If you fork(), you must follow that with an  
exec*() call of some sort, and you should not use CoreFoundation APIs  
within the child, before the exec*(). The applies to all higher-level  
APIs which use CoreFoundation, and since you cannot know what those  
higher-level APIs are doing, and whether they are using CoreFoundation  
APIs, you should not use any higher-level APIs either. This includes  
use of the daemon() function.

Additionally, per POSIX, only async-cancel-safe functions are safe to  
use on the child side of fork(), so even use of lower-level libSystem/ 
BSD/UNIX APIs should be kept to a minimum, and ideally to only async- 
cancel-safe functions.

This has always been true, and there have been notes made of this on  
various Cocoa developer mailling lists in the past. But CoreFoundation  
is taking some stronger measures now to "enforce" this limitation, so  
we thought it would be worthwhile to add a release note to call this  
out as well. A message is written to stderr when something uses API  
which is definitely known not to be safe in CoreFoundation after  
fork(). If file descriptor 2 has been closed, however, you will get no  
message or notice, which is too bad. We tried to make processes  
terminate in a very recognizable way, and did for a while and that was  
very handy, but backwards binary compatibility prevented us from doing  

If a process forks and a corefoundation unsafe function is used, you  
get a warning in the console:

The process has forked and you cannot use this CoreFoundation  
safely. You MUST exec().
Break on

to debug.

This can quickly clog the console and log files.  While it doesn't  
seem to affect GRASS, an improperly-built TclTk can cause trouble.  I  
ran into this when testing NVIZ for the pixmap/pbuffer export bug.

I've updated the OSX Readme TclTk build example to include an extra  
configure option:


Since the example is for an X11 TclTk build, CoreFoundation isn't  
really necessary, so this is OK.

And, though the warning log problem is Leopard-only, the forking is  
still a potential issue with earlier OSX versions, so this option  
should be used for all OSX versions.

For a TclTk Aqua build (for those that are willing to brave other  
problems), CoreFoundation is needed.  It is currently only partially  
fixed in Tcl (8.4 and 8.5) - for 64bit only, though it also happens in  
32bit mode.

William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>

"I ache, therefore I am.  Or in my case - I am, therefore I ache."

- Marvin

More information about the grass-dev mailing list