apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [design] work around new apr_poll leakage?
Date Fri, 19 Jul 2002 06:02:17 GMT
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;



Mime
View raw message