apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: no replacement for ap_spawn_child's functionality?
Date Fri, 23 Nov 2001 19:25:46 GMT
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?

>>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.

Stas Bekman             JAm_pH      --   Just Another mod_perl Hacker
http://stason.org/      mod_perl Guide   http://perl.apache.org/guide
mailto:stas@stason.org  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/

View raw message