From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26594 invoked by alias); 23 Sep 2008 18:30:33 -0000 Received: (qmail 26582 invoked by uid 22791); 23 Sep 2008 18:30:32 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 23 Sep 2008 18:29:57 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id E435E2A962B; Tue, 23 Sep 2008 14:29:54 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SH+KMQ0Gn+pN; Tue, 23 Sep 2008 14:29:54 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 8A4B32A95DD; Tue, 23 Sep 2008 14:29:52 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id DB44BE7ACD; Tue, 23 Sep 2008 11:29:43 -0700 (PDT) Date: Tue, 23 Sep 2008 18:30:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [RFA/Ada] Implement Ada tasking support Message-ID: <20080923182943.GA3729@adacore.com> References: <20080922233209.GE24389@adacore.com> <20080923150717.GF23372@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00480.txt.bz2 > > An Ada task carries with it a lot of semantic information thanks > > to the Ada Task Control Block (the ATCB). > > So it is a kind of thread on steroids? You can say that. However: > Can there ever be more or less than exactly one thread per Ada task? An Ada task *usually* lives on a thread, but nothing prevents the implementation to implement this differently. For instance, we used the FSU threads for a while, and I think the scheduling was done using signals, rather than using the system thread library. So this is not something required by the language. > We could extend the thread commands to display that additional info if > available. I am trying to find a way to mix the two that I wouldn't find really confusing. Also, there isn't always a 1:1 correspondance between an entry in the thread list and the entries in the Ada task list. I think it's on Solaris (or is it GNU/Linux?) where you have multiple entries in the thread list even though you really have one logical thread (from the software point of view). I think this is because the thread list shows everything that the system reports, LWPs, threads, kernel threads sometimes, etc. Also, you might sometimes have Ada tasks that appear in the task list as "Terminated" - it is possible that the underlying thread no longer exist. The Ada task list has this nice property that it sits at the software-level, whereas the thread list sits more at the system level. That's why I was saying that the two concepts (threads vs Ada tasks) serve different purposes. > I'm trying to establish whether they are irreconcilable. If they can > live together, I'd suggest to merge them. I think these are very interesting questions. In my opinion, they are, for the various reasons explained above. But perhaps you have some suggestions that might answer my concerns? -- Joel