From owner-freebsd-current Thu Sep 10 14:47:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA04949 for freebsd-current-outgoing; Thu, 10 Sep 1998 14:47:43 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA04928 for ; Thu, 10 Sep 1998 14:47:39 -0700 (PDT) (envelope-from smp@Ilsa.StevesCafe.com) Received: from Ilsa.StevesCafe.com (localhost.StevesCafe.com [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.8/8.8.5) with ESMTP id PAA06138; Thu, 10 Sep 1998 15:46:47 -0600 (MDT) Message-Id: <199809102146.PAA06138@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0.2 2/24/98 From: Steve Passe To: Terry Lambert cc: joelh@gnu.org, obrien@NUXI.com, dfr@nlsystems.com, jb@cimlogic.com.au, current@FreeBSD.ORG Subject: Re: Compiler problems with gcc-2.7.2.1 In-reply-to: Your message of "Thu, 10 Sep 1998 20:21:15 -0000." <199809102021.NAA20490@usr07.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Sep 1998 15:46:46 -0600 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry, > > Wrong: dh->top_elt is NOT the same as top_elt. The thread patches create > > a per-thread dhc headed by the dh struct, and thus have a per-thread top_elt > > which is referenced as dh->top_elt, NOT top_elt. The global top_elt > > is NOT used in a threaded program. > > Ok, now I'm confused. > > Why should it be, except for the initial thread in the case that > other threads have not been started? > > I.e., in what way does it differ from errno references? Not sure exactly what your asking here... Every thread has its own private stack and "owns" its own c++ objects. Thus the destructors for each thread's c++ objects are referenced in its per-thread stack (and per-thread dhc). When a throw occurs the system winds back up the dhc running each of those destructors eventually reaching the associated catch{} block (or not, in my failing version). Even the initial thread has this per-thread stack as oppossed to the "global" stack. In other words, the thread that does the throw walks up its stack towards its catch block hitting terminate if none exists. If its a problem for a specific thread to end the process async to other threads the programmer must code some sort of sync as part of the catch code. > You can't want all threads to attempt to close all descriptors on > exit (for example)... > They wouldn't, as above, only the 1 thread actually executes this code, the others are oblivious unless informed by the throw{}ing thread. > But then, I'm running the code on 2.2.6, without the patches that > take the threads implimentation away from pure Draft 4... So are we, with the exception of several bug fixes we have identified and applied locally. This isn't really a threads issue, its a "threads programmed in c++" issue. Without the patches we're discussing, threads attempt to manipulate a singular dhc anchored at top_elt (an internal c++ compiler built feature), but using their own unique stack (a pthreads feature). This quickly gets hosed, and a lock or segfault occurs. With the original patches the dhc is made per-thread, so the linked list nature of the dhc remains intact, but my additional patch is needed to enable the __throw code to find the per-thread top_elt of its per-thread dhc. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message