httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: memory leak on daedalus
Date Thu, 19 Jul 2001 11:47:25 GMT
rbb@covalent.net writes:

> On Wed, 18 Jul 2001, GUMMALAM,MOHAN (HP-Cupertino,ex2) wrote:
> 
> > So why are we setting up a socket connection in ap_mpm_pod_signal() in the
> > first place?  To me it seems that is uncalled for.
> >
> > I have noticed that the apr_poll_socket_add(pollset, pod->pod_in,...) is not
> > being done in worker_thread() !  Any specific reason why?
> >
> > I have implemented apr_poll_socket_add(pollset, pod->pod_in, APR_POLLIN),
> > and removed the socket call from ap_mpm_pod_signal(), and preliminary sanity
> > checks show that things are working fine.
> >
> > So is there something that I am missing?  Must be, because opening a socket
> > connection to force a select call to succeed is not a bright solution IMO.
...
> The reason for not doing the poll on the pod, is that if we add the pod to
> the select, then we are forced to do a select, even when we are only
> listening on one port.  We had the design you are trying months ago, and
> stopped using it so that we could use SINGLE_LISTEN_UNSERIALIZED_ACCEPT,
> and try to combine a lot of common code.

And when we do a select() we are further hampered by the requirement
for a cross-process mutex since select() -- unlike accept() -- does
not have wake-one semantics (see "thundering herd").

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Mime
View raw message