From: <[EMAIL PROTECTED]>
Sent: Tuesday, July 24, 2001 5:53 AM
> dreid 01/07/24 03:53:06
>
> Modified: threadproc/beos thread.c
> Log:
> dummy_func != dummy_worker
>
> I'm sorry, but this change seems crazy to me. Know I haven't been following
> the discussion that closely - how many patches????
Plenty. Leaving Aaron some slack for the original patch's grokability and
several
extra args (rather than our single extra apr_thread_t private arg), this really
hasn't changed that much. There was a brief detour to option 2. below, but any
which way, speak up when something isn't looking quite right :)
> but this doesn't feel right. Adding more indirections to gain what exactly?
I explained it this way on the phone last night, chatting with rbb...
Any coder porting to apr threading already has their void *data arg all defined,
and knows precisely what they are accomplishing with it. The choices were;
1. make the user responsible for getting the thread or pool data to the thread
(very, very unwieldly).
2. wrap their already tested void*data arg into _our_ structure. Very clumsy,
regardless if they could directly access it or were required to use
accessors
to set it and get it back.
3. Pass another arg. This means we aren't messing with their argument
whatsoever.
Number three seems like the most natural extension of these options. It allows
us
to perform whatever magic is required in the individual threads to support
thread
private data or whatever other extensions we might add later on, and do so
somewhat
transparently. And it allows the apr_thread_exit call to accept the arg
straight
from the arg passed to their thread_handler.
Does this help answer your objections before folks move forward?
Bill
