I maintain a RO.DS9, a cross-platform Python module that controls ds9 (a.k.a. SAOImage DS9), an astronomical image viewer.
The module starts by launching ds9 with a window of a known name (this is required to further command it), and that's where I run into trouble on MacOS X. On unix and Windows ds9 is an executable that I run using subprocess.Open and provide the necessary command-line arguments to set the window name. That works fine. On MacOS X I used to do the same thing. The application is a bundle "SAOImage DS9.app" that contains the executable ds9 that takes the same command-line arguments. Running ds9 still works on Leopard, but results in the nasty warning: The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). >From a google search, I found this: ------- This is caused by programs that use the fork() or daemon() function in combination with higher-level APIs. In Leopard you cannot use the CoreFoundation (CF...) APIs on the child side of a fork() without following it with an exec*() function. This has always been true, but Leopard is much more stingy about this kind of thing. So clearly I should not be doing this. But what to do instead? The simplest, but inadequate, alternative is to use subprocess to run the command "open -a SAOImage DS9". This works but I can't send command-line arguments, so I can't control the name of the window, which cripples the module. Is there some Mac-safe way to start the ds9 command-line application from my python module? I don't really know what it means to "run an exec*() function after a fork" and didn't think I was forking anything anyway -- I'm trying to start an independent process. I fear that the fork may be in ds9 itself and that there's nothing I can do, but I hope I'm wrong. -- Russell _______________________________________________ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
