From: "Ryan Bloom" <[EMAIL PROTECTED]> 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?
