[EMAIL PROTECTED] 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 | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
