Mailing-List: contact cvs-help@apr.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@apr.apache.org
Errors-To: <wrowe@rowe-clan.net>
Message-ID: <075601c11452$f746ca50$93c0b0d0@roweclan.net>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
To: <dev@apr.apache.org>, <apr-cvs@apache.org>
References: <20010724105306.35104.qmail@icarus.apache.org>
Subject: Re: cvs commit: apr/threadproc/beos thread.c
Date: Tue, 24 Jul 2001 10:10:13 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

From: <dreid@apache.org>
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