Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 06 Jun 1998 16:08:58 -0700
From:      Amancio Hasty <hasty@rah.star-gate.com>
To:        John Birrell <jb@cimlogic.com.au>
Cc:        nirva@ishiboo.com, rhh@ct.picker.com, multimedia@FreeBSD.ORG
Subject:   Re: Remote device multiplexing 
Message-ID:  <199806062308.QAA11624@rah.star-gate.com>
In-Reply-To: Your message of "Sat, 06 Jun 1998 16:34:25 %2B1000." <199806060634.QAA01014@cimlogic.com.au> 

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806062308.QAA11624>