> -----Ursprüngliche Nachricht----- > Von: Joe Orton > Gesendet: Mittwoch, 18. Juni 2008 17:20 > An: Ruediger Pluem > Cc: APR Developer List; dev@httpd.apache.org > Betreff: Re: showstopper to 1.3.1? > > On Sat, Jun 14, 2008 at 11:24:43PM +0200, Ruediger Pluem wrote: > > So the code before said that if port_getn returns -1 (== > fails) we return APR_TIMEUP > > if the error is ETIME or EINTR and APR_EGENERAL. > > So IMHO the error message (in this IMHO the same) would > have been shown with the old > > code. > > What is more strange to me is that we get a timeout error > ((70007)The timeout specified has > > expired: apr_pollset_poll:) even thought we called > apr_pollset_poll with -1 as timeout which > > means wait indefinitely or no timeout. The implementation > of apr_pollset_poll seems to be > > correct as it ensures that we supply NULL in this case to > port_getn. But OTOH the man page > > for port_get / port_getn documents timeout behaviour only > for port_get (setting timeout parameter > > to null means not timeout) not for port_getn. So couldn't > this be a Solaris bug? > > It may be working as designed - this code path gets trigged > when all the > fds in the pollset get closed asynchronously; see PR 42829 and the > thread concerning that bug on this list.
So do I get it correct that port_getn if called only with closed fd's associated to this port returns immediately with ETIME set as errno despite its timeout being set to infinite? > > If it is working as designed it is arguably more useful than > the epoll > behaviour in the same case; at least, it's more useful for httpd. > AFAICT the only effect of this to prefork is to generate some > error_log > spam; could be ignored easily enough. > > The APR change r641661 certainly looks correct anyway. As I understand it an error would be returned by apr_pollset_poll with and without r641661 in place. Regards Rüdiger
