Messages in this thread | | | Date | Sun, 27 Apr 2003 23:44:15 -0400 | From | Mark Mielke <> | Subject | Re: [RFD] Combined fork-exec syscall. |
| |
On Sun, Apr 27, 2003 at 09:43:38PM -0400, Mark Grosberg wrote: > The idea would be that the file mapping array would be easier to scan > (kind of like how poll() is a lot easier than select()).
This brings up the whole poll() vs select() vs /dev/poll vs ... discussion.
poll() is not necessarily faster than select(). If FD_CLOEXEC is not fast enough, then perhaps efforts should be put into improving FD_CLOEXEC in the kernel, rather than implementing a new system call that nobody will use because it isn't defined by POSIX. If the argument is that vfork(), exec() must scan the file descriptors to determine which ones have FD_CLOEXEC set, then perhaps the answer is to index the FD_CLOEXEC bits of file descriptors?
> > if you look at such webservers they tend to have a separate process just > > for the purpose of spawning cgi/etc. and use some IPC to pass the data to > > the cgi spawner. > Yup. I suppose for Apache this could be an alternate interface of the APR > spawn process function.
The Apache 2.0 documentation refers to mod_cgid as a method of avoiding the scenario that involves fork() copying all threads, not fork() scanning all file descriptors. Other than complexity of having a separate 'spawning daemon', I'm not sure that providing a spawn() system call would make things any faster. A CGI is going to take a fair amount of time to complete regardless of where it is spawned from. If you need speed, write your own mod_feature.c, or use an alternative such as mod_perl.
mark
-- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them...
http://mark.mielke.cc/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |