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 22:44:01 GMT
On Mon, Jul 23, 2001 at 12:55:51PM -0500, William A. Rowe, Jr. wrote:
> 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);

Quick implementation question. I've got this working as described above
under UNIX, but I'd like to do this correctly and I've run into a small
issue.

I'm not seeing a reason for having apr_thread_info_t in the first place,
and I think we should just override apr_thread_t with the data we need.
It's already private, and OS2 is already doing it this way. Are there
any reasons I wouldn't just do it the same way? We would end up with
something like this:

typedef void *(APR_THREAD_FUNC *apr_thread_start_t)(apr_thread_t *apr_info, void *usr_info);

(either I'm missing something, or I don't know why I didn't offer this up
before as a compromise.)

-aaron


Mime
View raw message