You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rasmus Lerdorf <ra...@lerdorf.on.ca> on 1998/07/24 18:23:53 UTC
r->connection->aborted no longer set?
In the PHP module I am checking r->connection->aborted while running a PHP
script and if set the PHP script will terminate gracefully. With Apache
1.2.6 if I write a little script that looks like:
<? while(1) print "Test"; ?>
And load it up and then hit my browser's stop button, I can tell on the
server that the script stops which means that r->connection->aborted got
set and PHP caught that.
However, in Apache 1.3.x this does not seem to be the case. I have
watched r->connection->aborted in gdb and it doesn't get set in this case.
I'll dive into the Apache code, but if someone can point me at what
changed, I would appreciate it.
-Rasmus
r->connection->aborted no longer set?
Posted by Ben Hyde <bh...@pobox.com>.
Rasmus Lerdorf writes:
> In the PHP module I am checking r->connection->aborted while running a PHP
> ...
ap_rwrite doesn't set it? - ben
Re: r->connection->aborted no longer set?
Posted by Dean Gaudet <dg...@arctic.org>.
On Sat, 25 Jul 1998, Ben Laurie wrote:
> Dean Gaudet wrote:
> >
> > Are you compiling with egcs? If so, try adding "volatile" to the aborted
> > field in conn_rec.
>
> Jeez, Dean, are you doing C++ these days?
Yeah, against my will of course.
Dean
Re: r->connection->aborted no longer set?
Posted by Manoj Kasichainula <ma...@io.com>.
On Mon, Jul 27, 1998 at 09:36:44AM -0700, Marc Slemko wrote:
> Except that egcs is a buggy compiler used mostly for its C++ support of
> things that the obsolete g++ doesn't support. That is why normally it is
> a fair bet that if someone is using it they are using it for C++.
Well, maybe I shouldn't be, but I use egcs now for all my compiles
because it has Pentium optimization (and Pentium pro too?). No
problems yet.
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"This letter is clearly the result of too much spinning." -- The Tick
Re: r->connection->aborted no longer set?
Posted by Marc Slemko <ma...@znep.com>.
On Mon, 27 Jul 1998, Alexei Kosut wrote:
> On Sat, 25 Jul 1998, Ben Laurie wrote:
>
> > Dean Gaudet wrote:
> > >
> > > Are you compiling with egcs? If so, try adding "volatile" to the aborted
> > > field in conn_rec.
> >
> > Jeez, Dean, are you doing C++ these days?
>
> I'm confused. Why do egcs or volatile imply C++? While egcs compiles C++,
> and volatile is a C++ keyword, egcs is also a C compiler, and volatile is
> a C keyword. In fact, as far as I know, the keyword means exactly the
> same thing in both C and C++. Has for years.
Except that egcs is a buggy compiler used mostly for its C++ support of
things that the obsolete g++ doesn't support. That is why normally it is
a fair bet that if someone is using it they are using it for C++.
Re: r->connection->aborted no longer set?
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Sat, 25 Jul 1998, Ben Laurie wrote:
> Dean Gaudet wrote:
> >
> > Are you compiling with egcs? If so, try adding "volatile" to the aborted
> > field in conn_rec.
>
> Jeez, Dean, are you doing C++ these days?
I'm confused. Why do egcs or volatile imply C++? While egcs compiles C++,
and volatile is a C++ keyword, egcs is also a C compiler, and volatile is
a C keyword. In fact, as far as I know, the keyword means exactly the
same thing in both C and C++. Has for years.
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
Re: r->connection->aborted no longer set?
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
>
> Are you compiling with egcs? If so, try adding "volatile" to the aborted
> field in conn_rec.
Jeez, Dean, are you doing C++ these days?
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/
Re: r->connection->aborted no longer set?
Posted by Dean Gaudet <dg...@arctic.org>.
Sheesh.
It doesn't make any code worse to add an extra (unsigned) cast to the left
of the (unsigned char) cast.
Dean
On Fri, 24 Jul 1998, Marc Slemko wrote:
> Oh yea, speaking of egcs, my version gives:
>
> util.c: In function `main':
> util.c:5: warning: subscript has type `char'
>
> when you pass a char to something like isspace() on Solaris. Sigh.
>
> Reading specs from /export/local/lib/gcc-lib/sparc-sun-solaris2.6/egcs-2.90.29/specs
> gcc version egcs-2.90.29 980515 (egcs-1.0.3 release)
> marcs@glurk:/tmp$ e
>
>
> On Fri, 24 Jul 1998, Dean Gaudet wrote:
>
> > Are you compiling with egcs? If so, try adding "volatile" to the aborted
> > field in conn_rec.
> >
> > Dean
> >
> > On Fri, 24 Jul 1998, Rasmus Lerdorf wrote:
> >
> > > In the PHP module I am checking r->connection->aborted while running a PHP
> > > script and if set the PHP script will terminate gracefully. With Apache
> > > 1.2.6 if I write a little script that looks like:
> > >
> > > <? while(1) print "Test"; ?>
> > >
> > > And load it up and then hit my browser's stop button, I can tell on the
> > > server that the script stops which means that r->connection->aborted got
> > > set and PHP caught that.
> > >
> > > However, in Apache 1.3.x this does not seem to be the case. I have
> > > watched r->connection->aborted in gdb and it doesn't get set in this case.
> > > I'll dive into the Apache code, but if someone can point me at what
> > > changed, I would appreciate it.
> > >
> > > -Rasmus
> > >
> > >
> >
>
>
Re: r->connection->aborted no longer set?
Posted by Marc Slemko <ma...@worldgate.com>.
Oh yea, speaking of egcs, my version gives:
util.c: In function `main':
util.c:5: warning: subscript has type `char'
when you pass a char to something like isspace() on Solaris. Sigh.
Reading specs from /export/local/lib/gcc-lib/sparc-sun-solaris2.6/egcs-2.90.29/specs
gcc version egcs-2.90.29 980515 (egcs-1.0.3 release)
marcs@glurk:/tmp$ e
On Fri, 24 Jul 1998, Dean Gaudet wrote:
> Are you compiling with egcs? If so, try adding "volatile" to the aborted
> field in conn_rec.
>
> Dean
>
> On Fri, 24 Jul 1998, Rasmus Lerdorf wrote:
>
> > In the PHP module I am checking r->connection->aborted while running a PHP
> > script and if set the PHP script will terminate gracefully. With Apache
> > 1.2.6 if I write a little script that looks like:
> >
> > <? while(1) print "Test"; ?>
> >
> > And load it up and then hit my browser's stop button, I can tell on the
> > server that the script stops which means that r->connection->aborted got
> > set and PHP caught that.
> >
> > However, in Apache 1.3.x this does not seem to be the case. I have
> > watched r->connection->aborted in gdb and it doesn't get set in this case.
> > I'll dive into the Apache code, but if someone can point me at what
> > changed, I would appreciate it.
> >
> > -Rasmus
> >
> >
>
Re: r->connection->aborted no longer set?
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 24 Jul 1998, Rasmus Lerdorf wrote:
> I think perhaps I am just confused. The request eventually does time out,
> but it takes a while. I was thinking that once the client browser breaks
> the connection by hitting his stop button, Apache would get a SIGPIPE or
> perhaps just an error when it tried to send the next byte and would thus
> set connection->aborted right away. Perhaps I am getting thrown by the
> output buffering here and the condition cannot be detected until Apache's
> buffer fills up which might take a while if the script doesn't have much
> output.
Yup, this is one of the features of the BSD sockets interface. You can't
find out a client has gone away until you write something to it. One way
to work around it is to send a space and rflush() every few seconds... it
sucks.
Dean
Re: r->connection->aborted no longer set?
Posted by Rasmus Lerdorf <ra...@lerdorf.on.ca>.
> Is this -X or running normally?
>
> If running normally, try disabling OPTIMIZE_TIMEOUTS in httpd.h.
Running normally with OPTIMIZE_TIMEOUTS $undef'ed didn't make a
difference.
> Otherwise, set a break point on alarm() and signal() ... is your php stuff
> maybe fooling with the alarms and signals?
put a trace on both. Nothing out of the ordinary. We are deliberately
not messing with signals.
I think perhaps I am just confused. The request eventually does time out,
but it takes a while. I was thinking that once the client browser breaks
the connection by hitting his stop button, Apache would get a SIGPIPE or
perhaps just an error when it tried to send the next byte and would thus
set connection->aborted right away. Perhaps I am getting thrown by the
output buffering here and the condition cannot be detected until Apache's
buffer fills up which might take a while if the script doesn't have much
output.
-Rasmus
Re: r->connection->aborted no longer set?
Posted by Dean Gaudet <dg...@arctic.org>.
Is this -X or running normally?
If running normally, try disabling OPTIMIZE_TIMEOUTS in httpd.h.
Otherwise, set a break point on alarm() and signal() ... is your php stuff
maybe fooling with the alarms and signals?
Dean
On Fri, 24 Jul 1998, Rasmus Lerdorf wrote:
> > is timeout() actually getting called?
>
> No, timeout isn't getting called. The relevant part of my mod_php3.c stub
> is:
>
> /* Assume output will be HTML. Individual scripts may change this
> further down the line */
> r->content_type = "text/html";
>
> /* Init timeout */
> hard_timeout("send", r);
>
> php3_save_umask();
> chdir_file(r->filename);
> add_common_vars(r);
> add_cgi_vars(r);
> apache_php3_module_main(r, fd, display_source_mode, preprocessed);
>
> /* Done, restore umask, turn off timeout, close file and return */
> php3_restore_umask();
> kill_timeout(r);
> #if WIN32|WINNT
> close(fd);
> #else
> pclosef(r->pool, fd);
> #endif
> return OK;
>
>
> The apache_php3_module_main() function is the entry point to PHP.
>
> -Rasmus
>
>
Re: r->connection->aborted no longer set?
Posted by Rasmus Lerdorf <ra...@lerdorf.on.ca>.
> is timeout() actually getting called?
No, timeout isn't getting called. The relevant part of my mod_php3.c stub
is:
/* Assume output will be HTML. Individual scripts may change this
further down the line */
r->content_type = "text/html";
/* Init timeout */
hard_timeout("send", r);
php3_save_umask();
chdir_file(r->filename);
add_common_vars(r);
add_cgi_vars(r);
apache_php3_module_main(r, fd, display_source_mode, preprocessed);
/* Done, restore umask, turn off timeout, close file and return */
php3_restore_umask();
kill_timeout(r);
#if WIN32|WINNT
close(fd);
#else
pclosef(r->pool, fd);
#endif
return OK;
The apache_php3_module_main() function is the entry point to PHP.
-Rasmus
Re: r->connection->aborted no longer set?
Posted by Dean Gaudet <dg...@arctic.org>.
What I said doesn't make sense anyhow...
is timeout() actually getting called?
Dean
On Fri, 24 Jul 1998, Rasmus Lerdorf wrote:
> > Are you compiling with egcs? If so, try adding "volatile" to the aborted
> > field in conn_rec.
>
> Nope, gcc-2.8.1
>
> -Rasmus
>
>
Re: r->connection->aborted no longer set?
Posted by Rasmus Lerdorf <ra...@lerdorf.on.ca>.
> Are you compiling with egcs? If so, try adding "volatile" to the aborted
> field in conn_rec.
Nope, gcc-2.8.1
-Rasmus
Re: r->connection->aborted no longer set?
Posted by Dean Gaudet <dg...@arctic.org>.
Are you compiling with egcs? If so, try adding "volatile" to the aborted
field in conn_rec.
Dean
On Fri, 24 Jul 1998, Rasmus Lerdorf wrote:
> In the PHP module I am checking r->connection->aborted while running a PHP
> script and if set the PHP script will terminate gracefully. With Apache
> 1.2.6 if I write a little script that looks like:
>
> <? while(1) print "Test"; ?>
>
> And load it up and then hit my browser's stop button, I can tell on the
> server that the script stops which means that r->connection->aborted got
> set and PHP caught that.
>
> However, in Apache 1.3.x this does not seem to be the case. I have
> watched r->connection->aborted in gdb and it doesn't get set in this case.
> I'll dive into the Apache code, but if someone can point me at what
> changed, I would appreciate it.
>
> -Rasmus
>
>