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: [PATCH] APR thread updates and associated httpd-2.0 changes
Date Mon, 23 Jul 2001 16:53:39 GMT
From: "Ryan Bloom" <rbb@covalent.net>
Sent: Saturday, July 21, 2001 11:55 AM

I spoke with rbb who is traveling, and finally persuaded him that exactly two
thread arguments are reasonable, one is the single "apr's private and otherwise
useful data", a private apr_thread_info_t, which the user can get from accessor 
calls, and the second is the single "user's own useful data", the traditional
void* of a thread create call.

I really don't want this apr structure public, but I also don't want the user
to be calling apr_thread_info_user_data_get() or some bogusness to accomplish
what any thread coder does with a void* on any sane implementation.

Can we accept two arguments to the user's thread fn?  One is private and requires
accessors to decypher, the other is private to the user's own application.
It's a pretty clear boundry, what _is_ apr's, and what _isn't_.

This would restore some binary compatibility, since all the private details are
consistent within the library itself.

> > > > Not if we hide this detail, I believe.  I don't know what that does
> > > > about providing access to the apr_thread_t in the child thread. 
> > > > Perhaps we declare the user's func as accepting arguments (apr_thread_t
> > > > *me, void *mine).
> > >
> > > That was where Aaron started, and I asked him to change it to this model.
> > > This model is more extensible moving forward IMHO.
> >
> > It makes binary compatibility much more fragile, so I can't parse your
> > meaning for 'extensible'.
> >
> > Some public types have little to no reason to change, e.g. apr_finfo_t.
> >
> > Those that are more dynamic need to stay private.
> Well, this is more extensible than passing everything as a separate 
> parameter, because it just requires a re-compile.  If we go to separate 
> parameters, then we require a code change.  I don't believe that the 
> requirements for this type will change anytime soon.  Currently, we are 
> passing the thread and the user's data, what else could EVERY thread need?

View raw message