httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael H. Voase" <mvo...@midcoast.com.au>
Subject Re: mod_cgi and thread safety
Date Thu, 04 Feb 1999 01:57:41 GMT
Ryan Bloom wrote:

> You are really going about this wrong.  The chdir needs to be done after
> the fork.  That is the key to this issue.

It is.

> You told me yesterday that it
> was being done after the fork, so mod_cgi should have been thread safe.
> In this e-mail, you are saying that the threads are doing the chdir.

In this email I am segesting that a seperate
thread safe chdir should be thought about so that
the threaded modules and can use if they want to .
cgi_child is calling chdir outside thread space and
as such is not affected .

>
> These are mutually exclusive statements.

Only when read into it that you think I am refering to
mod_cgi .  I know mod_include may need a chdir function
sometime  in the future, but mod_cgi doesnt require it ..

> When I fork a new processes to
> run my cgi, I want to do my chdir.  That won't affect my server process.
> I don't care about any threads in the newly forked process.  Those should
> all be dead, except for the currently executing thread.  Once the chdir is
> done, I execute my cgi, and return appropriately.
>
> I have a hard time believing that the chdir is being done in the cgi
> process in the current code.  I don't believe it is, because in mod_cgi,
> we chdir at least twice.  Once before we exec and once after.  There is no
> reason to chdir the second time if we are in the cgi's process, because it
> is about to die, and why do we care where in the file tree it is when it
> goes away?

Ok .. it is becoming quite obvious here that it is
you that is missing something or we are looking at
two different versions apache-apr . If the latter is the
case then I must make the disclaimer that the follwoing
points that I am making  are based on apache-apr
as I have downloaded from the cvs repository at
anoncvs.apache.worldgate.com and have updated nightly
ever since . If you have a different version then of course
all my arguments here are invalid .

First up , in the current
incarnation of mod_cgi  , chdir is called once and once only .

Secondly that call is made from cgi_child which is a forked process.

The sequence goes like this .
cgi_handler is activated by process request when http_main
recieves a request for a given cgi process ( as defined in the config file)

cgi_handler does its normal sanity checks , calls ap_setup_client_block
gets the arguments for the script and calls ap_bspawn_child .
(I thought this function would have given itself away by its title ...)
In the call to this function one of the parameters that are passed is
the pointer to cgi_child . Note here that chdir is never referred to
throughout cgi_handler and that cgi_handler never calls cgi_child
directly .

Now in ap_bspawn_child the first function it calls is spawn_child_core .
spawn_child_core then creates the pipes to be used  to communitcate
with the script . The function then calls fork . Between mod_cgi calling
ap_bspawn_child and this fork call , chdir has not been called .

    From here , the fork returns twice as usaul , once as the calling
thread , the other as the child process . Each process as then
completes the maintainance of the pipes (duping and closing unused
desriptors etc ) . The parent process ( its labelled clearly in the source )
then returns back to ap_bspawn_child which does more pipe maintainance
and returns to cgi_handler . The child process however calls the function
passed to it from ap_bspawn_child ( which was , earlier passed to it by
the calling function ) .  In the case of mod_cgi this function *is* cgi_child
which gets called as a *child* process and which then calls ap_chdir_file
in a 100% thread safe and valid way .
( I thought its name would give it away too ...)

    I hate to give long winded discussions on the internals of programs
but I feel that you really must go back and look at the source Mr Bloom .
I spent hours wading through mod_cgi due to mod_cgisock .


>
>
> I think we need to look at this code again, and determine where the chdir
> is being done and where it should be being done.
>
> Ryan
>

Again I contentend that the existing implementation is valid . Only calls
my by modules in thread space ( like mod_include ) need an alternate
abstraction that is thread safe . By tying chdir into the  fork call will only
limit its flexibility and hide the fact that the real
issue here is that chdir needs an abstraction that can be called
safely from the threaded processes . If you are looking to call seperate
forked functions then use ap_bspawn_child . Its a great little function
that nicely hides the ugliness of setting up three pipes to your
subsequent function , which will be forked off as a seperate
process . Once that function is forked off , all the issues related
to shared variables are relieved .

Cheers Mik Voase.

PS . This is me last word on this matter and Ill shut up and
go away now . You lot can haggle it out amongst yourselves ...

--
----------------------------------------------------------------------------
 /~\     /~\            CASTLE INDUSTRIES PTY. LTD.
 | |_____| |            Incorporated 1969. in N.S.W., Australia
 |         |            Phone +612 6562 1345 Fax +612 6567 1449
 |   /~\   |            Web http://www.midcoast.com.au/~mvoase
 |   [ ]   |            Michael H. Voase.  Director.
~~~~~~~~~~~~~~          Cause Linux Flies and Windoze Dies ... 'nuf said.
----------------------------------------------------------------------------




Mime
View raw message