From owner-freebsd-multimedia  Sat Jun  6 16:09:44 1998
Return-Path: <owner-freebsd-multimedia@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id QAA06621
          for freebsd-multimedia-outgoing; Sat, 6 Jun 1998 16:09:44 -0700 (PDT)
          (envelope-from owner-freebsd-multimedia@FreeBSD.ORG)
Received: from rah.star-gate.com (rah.star-gate.com [209.133.7.234])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA06594
          for <multimedia@FreeBSD.ORG>; Sat, 6 Jun 1998 16:09:13 -0700 (PDT)
          (envelope-from hasty@rah.star-gate.com)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1])
          by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id QAA11624;
          Sat, 6 Jun 1998 16:08:59 -0700 (PDT)
          (envelope-from hasty@rah.star-gate.com)
Message-Id: <199806062308.QAA11624@rah.star-gate.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: John Birrell <jb@cimlogic.com.au>
cc: nirva@ishiboo.com, rhh@ct.picker.com, multimedia@FreeBSD.ORG
Subject: Re: Remote device multiplexing 
In-reply-to: Your message of "Sat, 06 Jun 1998 16:34:25 +1000."
             <199806060634.QAA01014@cimlogic.com.au> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 06 Jun 1998 16:08:58 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-freebsd-multimedia@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

I am going to send mail to the ACE group to see if they can fix the
recursive exit problem that we are seeing over here.
pthread exit is pthread_exit and thread's hex id 
start cleanup is cleanupspecific
lock number is a key's access lock number

clean destructor is when cleanupspecific calls a destructor
clean return <phew the destructor return to cleanup specific.
thr exit is ACE calling thread exit.

locking the thread list for "thread id" is when a thread is
about to be placed in the dead list.

My take is that our pthread package can not handle recursive
pthread exits. I tried getting around this by adding a 
an exit_flag to the thread structure and fixing the access lock
on the key table by relesing the lock before calling
the destructor however we get stuck somewhere else now:

                                _spinlock(&key_table[key].access_lock);

                                if (key_table[key].allocated) {
                                        if (_thread_run->specific_data[key]) {
                                                data = (void *) _thread_run->
specific_data[key];
                                                _thread_run->
specific_data[key] = NULL;
                                                _thread_run->
specific_data_count--;
                                                printf("clean destructor key 
%d  data_count %d \n",key,
                                                        _thread_run->
specific_data_count );
                                            /* Unlock the key table entry: */
                                                destructor = 
key_table[key].destructor;
                                                _atomic_unlock(&key_table[key].
access_lock);
                                                if (destructor)
                                                        destructor(data);
                                                printf("clean return  
destructor \n");
                                        }
                                } else {
                                /* Unlock the key table entry: */
                                _atomic_unlock(&key_table[key].access_lock);
                                }


                        } else {
                          printf("cleanup exit  %x \n", _thread_run);
                                free(_thread_run->specific_data);
                                _thread_run->specific_data = NULL;
                                return;
                        }

I think is easier if the ACE group prevents the stupid recursive exit
call.

	Cheers,
	Amancio

{root} ./Task_Test
pthread exit 8053400 
start cleanup 8053400 
lock 0 
clean destructor key 0  data_count 1 
clean return  destructor 
lock 1 
lock 2 
clean destructor key 2  data_count 0 
thr exit 
pthread exit 8053400 
already exiting 
clean return  destructor 
cleanup exit  8053400 
locking the thread list for 8053400 : key[2].access 0 
pthread exit 8053200 
start cleanup 8053200 
lock 0 
clean destructor key 0  data_count 1 
clean return  destructor 
lock 1 
pthread exit 8053800 
start cleanup 8053800 
lock 0 
clean destructor key 0  data_count 1 
clean return  destructor 
lock 1 
pthread exit 8053600 
start cleanup 8053600 
lock 0 
clean destructor key 0  data_count 1 
clean return  destructor 
lock 1 



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-multimedia" in the body of the message