apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: no replacement for ap_spawn_child's functionality?
Date Fri, 23 Nov 2001 19:51:33 GMT
On Friday 23 November 2001 11:25 am, Stas Bekman wrote:
> Ryan Bloom wrote:
> >>>>so how is this solved in 1.3.x? Or is it not used for portable modules?
> >>>>I see (grep) that at least mod_rewrite and http_log use it in core.
> >>>
> >>>Take a look at the implementation of spawn_child_core on Windows though.
> >>>It isn't actually creating a new process.  Near as I can tell, it is
> >>>doing all of the work in a thread from the original process.  I can't
> >>>find where the thread is created, but we also don't have any function to
> >>>create a new process.
> >>
> >>Can we do the same workaround for apr? it was very slick to be able to
> >>pass a function to run to a spawned child and not to worry about IO
> >>pipes setup, exec_cleanup, etc. Now people will have to code their own
> >>fork() with a bunch of other things, and make things not very portable
> >>
> >>:( APR already includes a lot of OS specific code surrounding fork()
> >>
> >>code, it'd be really a pity not to be able to use this knowledge.
> >
> > We don't actually include any non-portable code to do fork.  I have been
> > toying with writing fork for Windows, but as I said earlier, it is really
> > hard to do.
> so do you think I can proceed with porting the code to use the
> ap_fork_..? and then at some point it'll be completely portable?

You should be able to, yes.

> >>I was also thinking to ask this: Is it possible to have some wrapper
> >>that will exec a process (and a func on my list) either in a spawned
> >>process or in a thread. e.g. if we running in the threaded env, the
> >>thread will be used to run the process, if we are in pre-fork run in the
> >>sub-process? The point is to hide all the complexity from the user code.
> >>You realize that if user writes his code to spawn a thread for doing
> >>some stuff it won't work with pre-fork and vice versa. What's apr take
> >>on this? I've read through all the .h files but couldn't find anything
> >>like this.
> >
> > I don't think this is a good idea.  We have looked at this in the past,
> > but in general the consensus has always been that programmers should
> > control if we are using threads or processes, not how APR was compiled.
> >
> >
> > I really think that the solution to this problem is to create fork() for
> > platforms that don't have one, and then create a spawn function around
> > it.
> So you say that unless you know that your code will run under threaded
> mpm, code for fork? But won't in some cases using the thread give a
> better performance? has anybody tested whether mod_cgi could be make
> faster if it's running its scripts in a thread? Or I guess this module
> is a bad example since it spends most of its time in script
> loading/running.

I am saying you a thread when a thread is appropriate, and a process when
a process is appropriate.  Ignore the MPM, because even the prefork MPM
can use threads if APR is compiled correctly.  Nobody has tested whether
mod_cgi could be made faster if it ran in a thread, because most CGI scripts
can't easily be run in a thread instead of a process.  Processes are the
correct solution for mod_cgi.


Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message