"Ryan Bloom" <[EMAIL PROTECTED]> writes:
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> >
> > "Ryan Bloom" <[EMAIL PROTECTED]> writes:
> >
> > > No, the old design was completely bogus. As proof, Trawick vetoed
> even
> > > using the damned thing inside of APR.
> >
> > I listed two conditions for the veto:
> >
> > 1) something more complex than calling poll() in that situation
> > 2) something slower than calling poll() in that situation
> >
> > It seems to me that the current code meets both conditions, though
> > not as obnoxiously as code using the older apr_poll() interface would
> > have.
>
> Can you clarify this please? Does that mean that you are vetoing the
> current code too? BTW, I don't understand how you can say that calling
> apr_poll() is more complex than calling poll(), since they have the same
> API. If your saying that they _only_ solution you will accept is
> calling poll() itself, then that is completely bogus.
You left out the pathlength issue... Calling anything which is a
wrapper around poll() is going to be deficient to calling poll() as
far as performance goes.
I'll backpedal on complexity since I forgot the need for
#ifdef HAVE_POLL
poll()
#else
select()
#endif
The current apr_poll() implementation seems to be optimize for the
very simple use of poll() as in apr_wait_for_io_or_timeout(), so I
will mostly agree with you and say that it is only a little more
complex to use apr_poll() when compared with calling poll() directly,
and the need for a select() flavor tips the balance in favor of using
the current apr_poll().
Am I vetoing? At the moment I'm willing to wait until we have a
usable apr_poll() implementation, at which point it will hopefully be
clear how apr_wait_for_io_or_timeout() should work.
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
