Naik, Roshan wrote:
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.
I do not think that Apache is that bad in this way. A quick review of the signal handlers showed that most times they only set flags which lets the currently running code leave loops, functions, etc and thus get up the call stack.
[..cut..]
>
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.
Ok, then you did far more work than I did. It was a general concern of mine and if you checked that this not the case it sounds fine. The good point of this discussion is the question: Does anybody know of any? If not it is very likely that there aren't any. One risk that remains left: From my experience band-aids (at least the good ones) remain longer then the time they have been designed for. So changes to these core resources might lead to problems later. Of course this is not the fault of the band-aid itself as it used in situations then where it has not been designed for.
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 ?
This is a general concern (maybe I am to negative :-)). I had in mind the folliwng things with this concern: After the fork the content handler may call Apache API functions. On some MPM's these API functions might expect some special threads which fulfil special tasks in these MPM's to be available. For example I am not sure if this is the case in the worker MPM. So what I would like to say: This simply needs to be checked. If it is not the case it is fine. As it is band-aid future MPM's should not matter here.
[..cut..]
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.
Just a quick thought: It might be possible with things like LD_PRELOAD or maybe with some tricks in the dl library, but I think if it is possible it is really ugly (my experience is based on Linux and Solaris).
[..cut..]
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.
Yes, this is true. My concern is that if the bleeding is stopped nobody will take care of the patient any longer. :-).
