2009/5/11 Gwynne Raskind <gwy...@darkrainfall.org>: > This is workable, but make sure you use a fork()/exec() pair to re-execute > yourself in that case, and use argc/argv in your main() to determine which > mode to run in. Don't just use fork() by itself - there are severe limits to > what you can do in an only-fork()ed process. What those limits are isn't > entirely clear to me; perhaps someone else could elaborate on that?
The main problem is that fork() kills all other threads in the child process, leaving you with only the thread that called fork() active. These threads are killed instantly no matter what they were doing, which means they could be holding exclusive resources. For example, if a thread was in the middle of a malloc() and held malloc's lock, it would never unlock and thus any calls you make to malloc() would deadlock. There are further troubles with shared resources like file descriptors, and resources that don't convey across, like window server connections, but in light of the inability to call even basic libc functions, this is not so important. For a list of what you can call, see the sigaction() man page. The list of functions that are safe to call from a signal handler is the same as what you can safely call between fork and exec. Mike _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
