Re: Task dispatching
Re: Task dispatching
- Subject: Re: Task dispatching
- From: Scott Ribe <email@hidden>
- Date: Tue, 13 Sep 2011 15:53:11 -0600
On Sep 13, 2011, at 3:07 PM, email@hidden 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
email@hidden
http://www.elevated-dev.com/
(303) 722-0567 voice
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden