RE: Fw: segfault in builtins-thread.c

> From: Ben Collins

> Looks like some bad logic, unless I'm just blind to what is happening:
>
> res = new_thread_object, which is set by new_thread_obj() 
> just after the thread is created, like this:
> 
>         aprerr = apr_thread_create(&new_thread, thread_attr,
> 				   thread_func, thread_data, 
> thread_pool);
> 	IF_APR_ERR("apr_thread_create") return NULL;
> 
> 	new_thread_object = thread_obj;
> 
> So the thread can be started, and call register_thread() 
> before new_thread_object is set. That's a race condition. 

Duh, I can't believe I put a race in there.  I must have taken my wrong
meds that day :) Thanks for finding it.  That whole area was messy.  I
also had error conditions just jumping out of code that had locks
surrounding it.  I added fixes for that in addition to the race you
fixed.

Kenny: The new fixes are in build 518.  Sorry for your trouble.  

Apparently your threads were switching faster than Ben's and mine, and
I'm even running on dual Opterons (go figure).  I even told my wife that
I had to get the dual Opterons in order to find things like this :-)
When I was chasing the multi-threaded object-locking bugs they would
show up much more readily on the dual-cpu than on a single-cpu machine.

> You 
> should pass the thread_obj to the new thread somehow. Using a 
> global like that passed around threads is asking for problems.

Yeah, that has always bothered me a little bit, but the thread creation
is locked to only one at a time so the current scheme is safe and there
is no real performance issue.  We can clean it up someday but there is
no rush.