linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Mielke <mark@mark.mielke.cc>
To: Mark Grosberg <mark@nolab.conman.org>
Cc: dean gaudet <dean-list-linux-kernel@arctic.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFD] Combined fork-exec syscall.
Date: Sun, 27 Apr 2003 23:44:15 -0400	[thread overview]
Message-ID: <20030428034415.GC32043@mark.mielke.cc> (raw)
In-Reply-To: <Pine.BSO.4.44.0304272140340.23296-100000@kwalitee.nolab.conman.org>

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/


  reply	other threads:[~2003-04-28  3:25 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-28  0:57 [RFD] Combined fork-exec syscall Mark Grosberg
2003-04-28  0:59 ` Larry McVoy
2003-04-28  1:16   ` Mark Grosberg
2003-04-28  1:36     ` Måns Rullgård
2003-04-28  1:45       ` Mark Grosberg
2003-04-28  1:49       ` dean gaudet
2003-04-28  1:59         ` Mark Grosberg
2003-04-28  2:27           ` Miles Bader
2003-04-28 19:07           ` dean gaudet
2003-05-01 13:14       ` Jakob Oestergaard
2003-04-28  1:17 ` Davide Libenzi
2003-04-28  1:28   ` Mark Grosberg
2003-04-29  2:01     ` Rafael Costa dos Santos
2003-04-28  1:41   ` Ulrich Drepper
2003-04-28  1:49     ` Mark Grosberg
2003-04-28  2:19       ` Ulrich Drepper
2003-04-28  6:59       ` Kai Henningsen
2003-04-28  1:35 ` dean gaudet
2003-04-28  1:43   ` Mark Grosberg
2003-04-28  3:44     ` Mark Mielke [this message]
2003-04-28  5:16       ` Jamie Lokier
2003-04-28  2:38   ` Davide Libenzi
2003-04-28  2:09 ` Richard B. Johnson
2003-04-28  2:12   ` Mark Grosberg
2003-04-28  2:42     ` Werner Almesberger
2003-04-28  6:35       ` Mark Grosberg
2003-04-29  2:47       ` Rafael Santos
2003-04-28  3:20         ` Werner Almesberger
2003-04-28 13:00     ` Richard B. Johnson
2003-04-28 13:22       ` Andreas Schwab
2003-04-28 13:57         ` Richard B. Johnson
2003-04-28 13:57           ` Andreas Schwab
2003-04-28 14:16             ` Richard B. Johnson
2003-04-28 14:38               ` Valdis.Kletnieks
2003-04-28 14:56                 ` Richard B. Johnson
2003-04-28 14:42               ` Andreas Schwab
2003-04-28 16:36       ` Mark Grosberg
2003-04-28 17:19         ` Davide Libenzi
2003-04-28 18:28         ` Craig Ruff
2003-05-06  2:48         ` Miles Bader
2003-04-29 18:50       ` Timothy Miller
2003-04-28  2:32   ` Werner Almesberger
2003-04-28  7:40 ` Mirar
2003-04-28 12:45 ` Matthias Andree
2003-04-29  1:05 ` Rafael Costa dos Santos
2003-04-28  1:19   ` Mark Grosberg
2003-04-29  1:29     ` Rafael Costa dos Santos
2003-04-28  3:03 Davide Libenzi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030428034415.GC32043@mark.mielke.cc \
    --to=mark@mark.mielke.cc \
    --cc=dean-list-linux-kernel@arctic.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark@nolab.conman.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).