Jeff, Fair enough. So the accept() will actually make the
well known socket "not readable" and other worker httpd
processes will not get "false" returns from select().
The solution would be to do the recvfrom() before releasing
the mutex.
Thanks,
Shail
Jeff Trawick wrote:
>
> Shail Bhatnagar <[EMAIL PROTECTED]> writes:
>
> > Jeff, The recvfrom() does not take place until process_connection() hook
> > is invoked. This is consistent with apache code, I think. So, one would
> > think that vanilla httpd processes ( without my changes) encounter the
> > same
> > problem ?? After the mutex is turned off and before the read/recv is
> > performed
> > there is a window of opportunity when other process/processes will enter
> > select()
> > and it will immediately return a positive value, indicating the socket
> > to be
> > readable. One has to set the O_NDELAY flag in these descriptors to work
> > around
> > this problem.
> >
> > Comments ??
>
> recvfrom() on your UDP socket is analogous to the accept() done on the
> apache listening socket in a couple of respects, one of which is
> locking requirements
>
> you want to allow only one select() pop for a given datagram (the
> mutex takes care of this) *AND* the thread for which select() popped
> must call recvfrom() before releasing the mutex; otherwise, as soon as
> you release the mutex select() can pop for another thread
>
> you can teach the code to recover if a thread is awakened and doesn't
> get a datagram, but performance will suffer due to extra dispatches
>
> --
> Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
