On May 8, 2013, at 5:41 AM, Ondrej Holecek wrote:
> The question is, how to force NSApplicationMain() to run in child.
>
> The basic idea is to do something like this:
>
> if (already running) {
> return cmd_main(argc, argv);
> } else {
> if (fork() == 0) {
> return NSApplicationMain(argc, (const char **)argv);
> } else {
> return cmd_main(argc, argv);
> }
> }
>
> The real code is there: http://pastebin.com/7LD2dPK8
>
> When I run NSApplicationMain() in child process, it simply does
> nothing. What's wrong?
It is not legal to do very much of anything on the child side of fork() other
than exec a new image. It's no longer online, but I'll quote from Apple's
Leopard release notes for Core Foundation:
"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 so."
Regards,
Ken
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
