httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shail Bhatnagar <shbha...@cisco.com>
Subject Re: Spurious return from select()
Date Fri, 10 Aug 2001 02:33:55 GMT
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 ??

Thanks,
Shail


Jeff Trawick wrote:
> 
> Shail Bhatnagar <shbhatna@cisco.com> writes:
> 
> > Jeff, Thanks for your response. I am
> > using the standard child_main() loop
> > in which select() is protected by the
> > mutex. The only difference is that the
> > parent is bound to a well known udp
> > port and so all children are monitoring
> > this well known port. Despite this mutex,
> > I see this behavior fairly consistently.
> > The frequency is more on solaris than on linux.
> 
> you are calling recvfrom() while still holding the accept mutex,
> right?
> 
> no other idea...
> 
> > The crash that I saw was in apr_pool_alloc_init().
> > apr_lock_create() failed, although there were
> > not permissions problems and then apr_lock_destroy()
> > crashed while accessing a NULL pointer.
> >
> > The relevant code fragment in apr_pool_alloc_init() is :
> > #if APR_HAS_THREADS
> >     status = apr_lock_create(&alloc_mutex, APR_MUTEX, APR_INTRAPROCESS,
> >                    NULL, globalp);
> >     if (status != APR_SUCCESS) {
> >         apr_lock_destroy(alloc_mutex);
> >         return status;
> >     }
> 
> well, clearly apr_lock_destroy() shouldn't be called if the mutex
> wasn't successfully created... I'll commit a fix in a jiffy
> 
> the question most interesting to me is why this apr_lock_create()
> failing for you and for noone else...  (I guess it just happened
> once?)
> 
> if you can manage to recreate, please run truss/strace on the program
> so we can see what syscall is failing, and with what errno
> 
> --
> 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