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


Mime
View raw message