apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@ebuilt.com>
Subject Re: [PATCH] APR thread updates and associated httpd-2.0 changes
Date Mon, 23 Jul 2001 17:24:00 GMT
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)?)

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

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)?


View raw message