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 ______________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
