httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Naik, Roshan" <roshan.n...@hp.com>
Subject RE: Bug: Apache hangs if script invokes fork/waitpid
Date Tue, 19 Oct 2004 23:43:54 GMT

> If I look at your patch at the end of the mail you would like 
> to exit the process once the handler has been run. I see the 
> following problems with that approach:
> 
> 1. exit(0): This does exactly what you do not like: A 
> function deeper down
>     in the call stack terminates the process. Furthermore 
> shared resources
>     may no get freed correctly. But this may be fixable by 
> doing it in the same
>     way Apache processes handle SIGTERM, SIGHUP and similar 
> signals. So I do
>     not see a real big problem here.


Right on! Which is why I call this "band-aid".
Unfortunately, the way Apache stands today, this idiom is not 
being followed, and I lack the ambition to fix that.



> 2. As fork is called inside the module code Apache gets caught by this
>     unprepared. So there may be some locks or similar things 
> on shared resources
>     that should be freed before a fork, especially if the 
> fork is used to
>     create an additional process for handling a time 
> consuming operation in the
>     background.


Your (legitimate) concern is essentially about the core Apache resouces
(i.e. ones not 
belonging to the handler Module, but the MPM and above) and locks that
(may) need
to be processed before/after a fork. 

If you can point out any instances of this then this is 
definitely a problem. I briefly looked around 
(prior to proposing the solutions) but couldn't find any.
Which means that if you were to register pre/post fork handlers
today in Apache worker thread prior to handing off to a content
handler, the handlers are most likely going to be empty
functions. My opinion is ofcourse based on my understanding 
which may be incomplete/incorrect.

I gave this some thought and felt that that it is unlikely 
to be a problem. 

My thinking in simple terms: Fork occurs inside the content 
handler module. So any duped rsources that belong the content
handler are the responsibility of the content handler. That
leave us with core Apache resouces (i.e. ones not 
belonging to the handler Module, but to the MPM and above). 

Since I call an immediate exit() when control returns to
a "grand child" apache process, we avoid the problem of double
cleanup on any apache resources. i.e grand child wont try to
close files or free locks (or shared memory or connections) 
belonging the real child. So I don't see much need for post fork
handler. That brings us to pre fork handler. I really don't know of
any such resources or locks held by Apache that need to be processed
prior to forking in the worker thread. Does anybody know of any ?
If there is any we can come up with a pre fork handler that does
this job.


> 3. On some Unix OS'es a fork does not copy all threads of the 
> original process
>     for performance reasons. So the forked process is not an 
> exact copy of the original
>     process. This may lead to problems with multithreaded MPM's.

My UNIX box (HP-UX) is exactly that kind of Unix and I am using 
worker MPM. Could you be more precise about what those problems 
are ?


> I think 2. and 3. can only be solved by having an appropriate 
> wrapper around fork inside of Apache that does the needed 
> preparations. 


3 cannot be solved without a precise definition of the problem.


> But this would require that the "unknowing" 
> module is made to call this wrapper when it calls fork.
> On Unix systems I think this is only possible by some ugly 
> and maybe not portable dynamic linker voodoo. I have no idea 
> how this can be reached on non Unix platforms.


Yes.... Which is why this rules out such brave attempts. :)
I cant think of how to do this on most UNIX platforms either.

 
> As far as I understand their ideas they also try to carefully 
> prepare a fork operation. I think their approach is driven 
> from the approaches used by mod_cgi which also forks 
> processes, but in a big difference to your problem also 
> executes a new program by calling an exec like call.
> 

Ok. My understanding of internals of mod_cgi(d) internals is fairly low
So I would like someone to throw light on that matter.
And also comments on whether other modules should be required 
to be equally smart. 


> > I feel it is useful to have this band-aid to stop the 
> > bleeding till we 
> > take it to the hospital.
> 
> Sorry, for sounding too sarcastic, simply could not resist:
> I am not quite sure if the patient will reach the hospital 
> alive with this band aid ;-).

:D 
Another concern is if the patient will ever get any help
or will he only be shown the prospects of better
cures. 


Mime
View raw message