Date: Thu, 10 Sep 1998 15:46:46 -0600 From: Steve Passe <smp@csn.net> To: Terry Lambert <tlambert@primenet.com> 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 Message-ID: <199809102146.PAA06138@Ilsa.StevesCafe.com> In-Reply-To: Your message of "Thu, 10 Sep 1998 20:21:15 -0000." <199809102021.NAA20490@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809102146.PAA06138>