Re: [design] work around new apr_poll leakage?

[William A. Rowe, Jr.]

At 11:21 PM 7/18/2002, Brian Pane wrote:
I'm almost in complete agreement with this proposal.  We
need a wrapper object to hold the temp pollset so that we
can re-use it for all subsequent poll calls on the same
fd set.
Notice that apr_pollfd_internal_t *int; below _IS_ entirely
opaque...  [and using a reserved keyword, the member name
REALLY sucked... how about simply *private.]
So,
 -1 on the current apr_poll code with the memory leak
 +1 on Bill's proposal to add the apr_pollfd_set_t wrapper object
 -0.5 on making the structures transparent
As long as we have an opaque accessor which we define
[and later redefine as needed] I don't see any huge problem
with keeping both apr_pollfd_t and apr_pollfd_set_t transparent.
Yes, we need extensible and very private storage, but I think
the design below for apr_pollfd_set_t accomplishes this.
Bill
William A. Rowe, Jr. wrote:
typedef struct {
    apr_pool_t *p;
    apr_pollfd_internal_t *int;
    apr_pollfd_t *first;
    int count;
} apr_pollfd_set_t;