httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: [PATCH] ap_xlateattr_t for passing options to ap_xlate_open()
Date Tue, 23 May 2000 20:07:44 GMT

Threadattr and procattr need to be opaque.  Take a look at the differences
between Windows and Unix implementations sometime.  I am about to commit a
change to make ap_proc_t's complete and thus non-opaque.  I am sure the
xlate stuff is opaque because that was the way APR was written when this
stuff we first started.  I have purposefully stayed away from the xlate
stuff recently.  I suspect that now that we are trying to "open up" a few
of the APR types, the xlate stuff may become a complete type.

Ryan

> I find the whole xlateattr/procattr/threadattr stuff hard to use. There
> aren't that many parameters here, and there is not a lot of calling points
> in the code. Just pass the dumb params to the function rather than
> interposing an opaque(!) structure in the way.
> 
> pthreads' threadattr makes some sense because it needs to be opaque for
> its cross-platform nature. The xlate stuff doesn't seem to need to be
> opaque. We support a specific set of parameters, which are well-defined
> and portable. Sure, they might be ignored on some platforms, but the
> calling code doesn't need to know that.
> 
> How many places do we use ap_xlate_open? If that happened in a bazillion
> places, then maybe the attr stuff would simplify the code. However, I
> don't see that we would really be sharing the attrs between the call
> points. This means each call would be something like:
> 
>     ap_xlate_create_xlateattr(&xattr, p);
>     ap_xlate_set_xlateattr_sb(xattr, 1);
>     ap_xlate_open(&set, xattr, ...);
> 
> instead of:
> 
>     ap_xlate_open(&set, 1, ...);
> 
> 
> I'll take the latter any day.
> 
> How many parameters do we really think will be added? And do we really
> have no idea what they would be? IMO, I'll take new constructor functions
> and deprecate the old instead of complicating every constructor and use.
> 
> Cheers,
> -g
> 
> -- 
> Greg Stein, http://www.lyra.org/
> 


_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message