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)?) > , 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. 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. 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. 2) the application needs an obvious way to be able to call apr_thread_exit() (it currently requires the apr_thread_t). 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. - updates to httpd that work with this. - updates to test/testthread.c that illustrate this. 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. - 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)? -aaron
