From: "Aaron Bannert" <[EMAIL PROTECTED]> Sent: Monday, July 23, 2001 12:24 PM
> On Mon, Jul 23, 2001 at 11:53:39AM -0500, William A. Rowe, Jr. wrote: > > 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 > > (having a little trouble parsing this. for clarity, what will be the > prototype of the worker_fn() -- (aka apr_thread_start_t)?) typedef void *(APR_THREAD_FUNC *apr_thread_start_t)(apr_thread_info_t *apr_info, void *usr_info); > > ...and the second is the single "user's own useful data", the traditional > > void* of a thread create call. > > > > This would restore some binary compatibility, since all the private details > > are > > consistent within the library itself. > > This sounds similiar to the original patch I posted on this subject > (the mega-patch that was rejected due to size :). The main difference > between this and my original patch was that I was passing in three > parameters: the apr private stuff, the > application private stuff, and an extra param for the apr_pool_t struct. > I was unaware of the accessor functions at that time. Yup, that sounds like why we all diverged into three directions at once :) > Whatever we decide on, would you all agree that it needs to solve these > requirements: > > 1) the application's thread needs access to the child-pool that was created > specifically for this thread. Yes. > 2) the application needs an obvious way to be able to call apr_thread_exit() > (it currently requires the apr_thread_t). I'd make your (apr_thread_info_t *) the argument to apr_thread_exit(). > Shall I cook up a final patch to get this done that does the following: > > - thread worker functions will now take 2 parameters, an apr_thread_t > and the application-private opaque void* data. No, the apr-private apr_thread_info_t *, and the app-private void* > - updates to httpd that work with this. Yes. A seperate patch :) > - updates to test/testthread.c that illustrate this. Yes. A seperate patch :) > Open issues (please comment separately): > > - apr_thread_join() is still broken, but I am hesitant to provide the fixes > for fear that they will conflict with previously posted patches. Let's close this first > - apr_thread_exit() takes an (apr_status_t*). Should that just be an > apr_status_t instead? Does the application really need to allocate heap > memory for a measily (int)? As look as we are fixing the args to apr_thread_exit :) If the platform has no idea about what to do with this, the apr implementation should have set aside an int in the apr_thread_info_t. Bill
