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 Sat, 21 Jul 2001 16:47:11 GMT
From: "Ryan Bloom" <rbb@covalent.net>
Sent: Saturday, July 21, 2001 11:09 AM


> > > Changed the worker routine's signature to take a single parameter:
> > > apr_thread_param_t, which contains the opaque data and the apr_thread_t.
> >
> > Can we simply hide the details, and use our own _thread_main starting
> > point? Put the thread start function ptr in this structure as well, have
> > our _thread_main unwrap whatever is required (and it can create
> > thread-local data, if we ever implement that), finally calling out to the
> > user's *func?
> >
> > > httpd-2.0 will have to be updated after applying this patch to APR.
> >
> > 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.


Mime
View raw message