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:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
