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 Mon, 23 Jul 2001 18:05:54 GMT
From: "Aaron Bannert" <aaron@ebuilt.com>
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" <rbb@covalent.net>
> > 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.


> 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.


View raw message