You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Michael H. Voase" <mv...@midcoast.com.au> on 1999/02/03 06:49:58 UTC
mod_cgi and thread safety
Gday,
Ive been testing out mod_cgi here under linux threads
and I cant fault it . It seems to behave well as it is and I
think the problem is with functions calling chdir from inside
the threads . If anyone wants to give me some
exapmles of where it dies , I'll be happy to look into it
further . The API abstraction for chdir will benefit the
modules and processes running within the server threads ,
however this doesnt seem to affect mod_cgi ( on linux
anyway ;-).
Cheers Mik Voase.
--
----------------------------------------------------------------------------
/~\ /~\ 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.
----------------------------------------------------------------------------
Re: mod_cgi and thread safety
Posted by "Michael H. Voase" <mv...@midcoast.com.au>.
Marc Slemko wrote:
> On Wed, 3 Feb 1999, Rodent of Unusual Size wrote:
>
> > Michael H. Voase wrote:
> > >
> > > I know mod_include may need a chdir function
> > > sometime in the future, but mod_cgi doesnt require it ..
> >
> > Erm, yes it does. CGI scripts are supposed to be started
> > with the cwd == the directory in which the script file is
> > located.
>
> Well, technically you can ignore that and certain Windows servers
> do, ie. don't change directories.
>
> I don't recommend that, but it is possible.
Lastly on the errata list ,
"cgi_child calls ap_chdir_file in a 100% thread safe way"
is really bad wording . Chdir isnt thread safe at all ,
thats what the entire issue is all about .
mod_cgi gets away with it only becase the call is
made from a forked process rather than from inside
thread space ...
( I know someone's gonna pick on me for this so I'll
get it of the way now to save traffic ... )
Cheers Mik Voase.
--
----------------------------------------------------------------------------
/~\ /~\ 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.
----------------------------------------------------------------------------
Re: mod_cgi and thread safety
Posted by "Michael H. Voase" <mv...@midcoast.com.au>.
Marc Slemko wrote:
> On Wed, 3 Feb 1999, Rodent of Unusual Size wrote:
>
> > Michael H. Voase wrote:
> > >
> > > I know mod_include may need a chdir function
> > > sometime in the future, but mod_cgi doesnt require it ..
> >
> > Erm, yes it does. CGI scripts are supposed to be started
> > with the cwd == the directory in which the script file is
> > located.
>
> Well, technically you can ignore that and certain Windows servers
> do, ie. don't change directories.
>
> I don't recommend that, but it is possible.
errm - sorry my mistake -
"doesnt require a chdir" should read
"doesnt require a thread safe chdir "
( I should have elaborated here .. my
appologies )
also "Only calls my by modules " should
read " Only calls made by modules "
I gotta proof read me messages better .. ;-)
Anyways now that the errata is out of the
way I can go back to lurking ...
Cheers Mik Voase.
--
----------------------------------------------------------------------------
/~\ /~\ 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.
----------------------------------------------------------------------------
Re: mod_cgi and thread safety
Posted by Marc Slemko <ma...@worldgate.com>.
On Wed, 3 Feb 1999, Rodent of Unusual Size wrote:
> Michael H. Voase wrote:
> >
> > I know mod_include may need a chdir function
> > sometime in the future, but mod_cgi doesnt require it ..
>
> Erm, yes it does. CGI scripts are supposed to be started
> with the cwd == the directory in which the script file is
> located.
Well, technically you can ignore that and certain Windows servers
do, ie. don't change directories.
I don't recommend that, but it is possible.
Re: mod_cgi and thread safety
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Michael H. Voase wrote:
>
> I know mod_include may need a chdir function
> sometime in the future, but mod_cgi doesnt require it ..
Erm, yes it does. CGI scripts are supposed to be started
with the cwd == the directory in which the script file is
located.
Regardless of how it happens, the cwd needs to be correct
when the CGI script is started. On Win32 this is done by
passing an argument to the Win32 create-a-child routine
(whatever it is). A thread-safe way to do the same on Unix
will be welcome indeed.
--
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Group member <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: mod_cgi and thread safety
Posted by "Michael H. Voase" <mv...@midcoast.com.au>.
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.
----------------------------------------------------------------------------
Re: mod_cgi and thread safety
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
You are really going about this wrong. The chdir needs to be done after
the fork. That is the key to this issue. 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.
These are mutually exclusive statements. 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?
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
On Wed, 3 Feb 1999, Michael H. Voase wrote:
> Gday,
> I dont usually reply to me own threads but
> no one seems to have shot me down in flames
> yet ( which is unusual ;-)
>
> As far as the chdir abstraction goes I segest
> creating a second a second API function for
> chdir using a thread safe method for functions
> calling chdir from within the treads and leaving
> the original ap_chdir_file abstraction
> for forking processes that dont run in thread
> space . BFIIK how to produce a working
> thread safe abstraction of chdir , considering
> that one will be delving deep into the roots of
> unix architecture to pull off a stunt like this .
> As such this is outside the scope of my
> humble capabilities ...
> ( maybe worth nagging the thread
> implementors about ??? )
>
>
> Cheers MikVoase.
>
>
>
> --
> ----------------------------------------------------------------------------
> /~\ /~\ 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.
> ----------------------------------------------------------------------------
>
>
>
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: mod_cgi and thread safety
Posted by "Michael H. Voase" <mv...@midcoast.com.au>.
Gday,
I dont usually reply to me own threads but
no one seems to have shot me down in flames
yet ( which is unusual ;-)
As far as the chdir abstraction goes I segest
creating a second a second API function for
chdir using a thread safe method for functions
calling chdir from within the treads and leaving
the original ap_chdir_file abstraction
for forking processes that dont run in thread
space . BFIIK how to produce a working
thread safe abstraction of chdir , considering
that one will be delving deep into the roots of
unix architecture to pull off a stunt like this .
As such this is outside the scope of my
humble capabilities ...
( maybe worth nagging the thread
implementors about ??? )
Cheers MikVoase.
--
----------------------------------------------------------------------------
/~\ /~\ 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.
----------------------------------------------------------------------------