On Sep 13, 2011, at 3:07 PM, jonat...@mugginsoft.com wrote:
> Are you sure about this?
Yes. From man fork:
There are limits to what you can do in the child process. To be totally
safe you should restrict yourself to only executing async-signal safe
operations until such time as one of the exec functions is called. All
APIs, including global data symbols, in any framework or library should
be assumed to be unsafe after a fork() unless explicitly documented to be
safe or async-signal safe. If you need to use these frameworks in the
child process, you must exec. In this situation it is reasonable to exec
yourself.
And from man sigaction, the list of async-signal safe calls:
Base Interfaces:
_exit(), access(), alarm(), cfgetispeed(), cfgetospeed(), cfsetispeed(),
cfsetospeed(), chdir(), chmod(), chown(), close(), creat(), dup(),
dup2(), execle(), execve(), fcntl(), fork(), fpathconf(), fstat(),
fsync(), getegid(), geteuid(), getgid(), getgroups(), getpgrp(),
getpid(), getppid(), getuid(), kill(), link(), lseek(), mkdir(),
mkfifo(), open(), pathconf(), pause(), pipe(), raise(), read(), rename(),
rmdir(), setgid(), setpgid(), setsid(), setuid(), sigaction(),
sigaddset(), sigdelset(), sigemptyset(), sigfillset(), sigismember(),
signal(), sigpending(), sigprocmask(), sigsuspend(), sleep(), stat(),
sysconf(), tcdrain(), tcflow(), tcflush(), tcgetattr(), tcgetpgrp(),
tcsendbreak(), tcsetattr(), tcsetpgrp(), time(), times(), umask(),
uname(), unlink(), utime(), wait(), waitpid(), write().
Realtime Interfaces:
aio_error(), sigpause(), aio_return(), aio_suspend(), sem_post(),
sigset().
ANSI C Interfaces:
strcpy(), strcat(), strncpy(), strncat(), and perhaps some others.
Extension Interfaces:
strlcpy(), strlcat().
> Looking at the apache mpm pre fork code it looks to me that the child
> executes the same image.
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/prefork/prefork.c?view=markup
>
> see make_child (which does the fork) and child_main (which is called in the
> child after the fork).
Not very useful. From that it's not clear whether one of the many many many
macros and library calls exec's a new image, or whether Apache's own extensive
runtime libraries are guaranteed async-signal safe because they are restricted
to using the very small set of system functions that are safe. I suspect the
latter. In particular, there's stuff about setting up memory pools that
suggests Apache uses its own memory allocation routines. Well just great, so
you don't need to exec if you provide your own memory management routines,
never use malloc, never use any system function that uses malloc, and write
your own entire runtime abstraction layer. Isn't that pretty much what I was
saying before?
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice
_______________________________________________
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
