You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ryan Bloom <rb...@covalent.net> on 2001/11/10 22:18:32 UTC
Re: cvs commit: httpd-2.0/server/mpm/winnt mpm_winnt.c
On Saturday 10 November 2001 01:07 pm, rbb@apache.org wrote:
> rbb 01/11/10 13:07:13
>
> Modified: include http_connection.h
> server connection.c
> server/mpm/winnt mpm_winnt.c
> Log:
> Fix the Windows MPM. Windows doesn't always use the lingering close
> function. If it can re-use the socket, we are better off not calling
> the function. To fix this, we re-expose the lingering_close function,
> and we allow the MPM to remove the cleanup.
Bill, can you make sure this fixes your problem? Long-term, this won't work,
but I want to keep the server working in the short-term. The reason this won't
work, is that you will never know if the lingering-close function has been
registered for any given connection. We'll have to figure out how to fix that,
but for now this will work.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: cvs commit: httpd-2.0/server/mpm/winnt mpm_winnt.c
Posted by Ryan Bloom <rb...@covalent.net>.
On Saturday 10 November 2001 04:33 pm, Jeff Trawick wrote:
> Ryan Bloom <rb...@covalent.net> writes:
> > On Saturday 10 November 2001 01:07 pm, rbb@apache.org wrote:
> > > rbb 01/11/10 13:07:13
> > >
> > > Modified: include http_connection.h
> > > server connection.c
> > > server/mpm/winnt mpm_winnt.c
> > > Log:
> > > Fix the Windows MPM. Windows doesn't always use the lingering close
> > > function. If it can re-use the socket, we are better off not calling
> > > the function. To fix this, we re-expose the lingering_close
> > > function, and we allow the MPM to remove the cleanup.
> >
> > Bill, can you make sure this fixes your problem? Long-term, this won't
> > work, but I want to keep the server working in the short-term. The
> > reason this won't work, is that you will never know if the
> > lingering-close function has been registered for any given connection.
> > We'll have to figure out how to fix that, but for now this will work.
>
> I liked somebody's (Greg Stein's??) idea recently where lingering
> close could be a hook or optional function which the MPM could
> implement (perhaps with a no-op). An MPM should be able to implement
> lingering close on its own. A single thread could be devoted to
> doing the lingering close.
>
> I'm not sure if the ability of an MPM to do this has changed
> recently. It seems weird to have to kill a cleanup in order to make
> it work.
The problem is that lingering close is tied VERY closely to the underlying
network mechanism. In fact, it only makes sense if you are dealing with
TCP directly. I can't see lingering close being useful with an SSL socket.
We can have the core implement the lingering_close thread, and have
two macros, MPM_WANTS_LINGERING_CLOSE and
MPM_WANTS_THREADED_LINGERING_CLOSE. This will allow the MPM
to override the core, while still allowing the core to implement lingering_close.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: cvs commit: httpd-2.0/server/mpm/winnt mpm_winnt.c
Posted by Jeff Trawick <tr...@attglobal.net>.
Ryan Bloom <rb...@covalent.net> writes:
> On Saturday 10 November 2001 01:07 pm, rbb@apache.org wrote:
> > rbb 01/11/10 13:07:13
> >
> > Modified: include http_connection.h
> > server connection.c
> > server/mpm/winnt mpm_winnt.c
> > Log:
> > Fix the Windows MPM. Windows doesn't always use the lingering close
> > function. If it can re-use the socket, we are better off not calling
> > the function. To fix this, we re-expose the lingering_close function,
> > and we allow the MPM to remove the cleanup.
>
> Bill, can you make sure this fixes your problem? Long-term, this won't work,
> but I want to keep the server working in the short-term. The reason this won't
> work, is that you will never know if the lingering-close function has been
> registered for any given connection. We'll have to figure out how to fix that,
> but for now this will work.
I liked somebody's (Greg Stein's??) idea recently where lingering
close could be a hook or optional function which the MPM could
implement (perhaps with a no-op). An MPM should be able to implement
lingering close on its own. A single thread could be devoted to
doing the lingering close.
I'm not sure if the ability of an MPM to do this has changed
recently. It seems weird to have to kill a cleanup in order to make
it work.
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...