Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 06 Jun 1998 03:29:56 -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:  <199806061029.DAA05773@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

Two ideas:

in cleanupspecific don't hold a lock while calling a destructor,
save the destructor's address, free the thread specific, call the
destructor.

or don't allow recursive exits..

	Cheers,
	Amancio

> Amancio Hasty wrote:
> > ACE it is in a little bad shape right now however John is working
> > out the kings in libc_r;however, JACE should do the job .
> 
> The problem with ACE is that the C++ code that is generated by g++
> version 2.7.2.1 (from current) is bogus. ACE declares destructors using
> thread specific keys. When the last of these destructors is called
> by libc_r from the _cleanup_specific function (as part of a thread
> exiting), it does not return to _cleanup_specific() where it should
> unlock the key table entry. Instead execution restarts in pthread_exit()
> as though _cleanup_specific() had returned. I don't see how I can
> program around that.
> 
> Following all those pissy little functions that C++ creates is really
> annoying. The amount of shit that ACE is doing in that destructor call
> is amazing. It tries to do as much thread management as libc_r is doing.
> Ugh. This stuff really shouldn't be layered on top of POSIX threads.
> It should have it's own built in threads to avoid all the duplication
> of code.
> 
> I guess I have to go to gcc 2.8.1 like the ACE web page says.
> 
> -- 
> John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/
> CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137



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?199806061029.DAA05773>