apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Saccoccio" <r...@fastcgi.com>
Subject RE: [PATCH] pollacc.c poll.c
Date Wed, 07 Aug 2002 00:28:47 GMT
> >>Alternatively, we could compact the aprset array in
> >>apr_poll_socket_remove().  This can be done in O(1)
> >>
> >>
> >
> >You can't do that because you don't own the apr_pollfd_t array,
> management
> >of the array is (now) the caller's responsiblity.
> apr_poll_socket_remove()
> >and kin are deprecated.
> >
>
> I disagree; the whole point of apr_poll_socket_remove() is
> to modify the array.  We can't avoid modifying the array--

I'm of course not suggesting that the array not be modified, only that you
can't move descriptors around.

> if we did, the API would no longer be compatible with old
> code.  We've only deprecated the API, not removed it, so

The existing code does not juggle descriptors in the array.  It only adds
new ones to empty slots and marks old ones as empty.

Your proposal requires the apr_pollfd_t array be packed.  The new API (no
accessors and a transparent array) does not suggest this is a requirement
and I think it would be a mistake to do so (thus doing so would break
compatibility).

My patch/approach does not break compatibility with either the new or the
old API.  The problem that it leaves is how to deal with the empty slot in
the pollfd array in the HAVE_POLL path in a cross platform manner.  This
problem is easily resolved by packing the pollfd array (which is not
exposed).

> it still has to work as advertised.  Similarly, the

And that is why I submitted the patch of course.

Another relevant angle is that the existing code is pretty broke and thus
compatibility breakage may be moot or at least welcome in favor of
advertised functionality.

The bottom line is that I really don't care how its fixed, only that it is.
But I do think it would be a mistake to require a packed apr_pollfd_t array
for use with apr_poll().

--rob






Mime
View raw message