> > > 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? Ryan _____________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -----------------------------------------------------------------------------
