From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9699 invoked by alias); 23 Sep 2008 18:06:31 -0000 Received: (qmail 9691 invoked by uid 22791); 23 Sep 2008 18:06:30 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout2.012.net.il (HELO mtaout2.012.net.il) (84.95.2.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 23 Sep 2008 18:05:46 +0000 Received: from HOME-C4E4A596F7 ([77.127.116.246]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K7N002CTUB7VR80@i_mtaout2.012.net.il> for gdb-patches@sourceware.org; Tue, 23 Sep 2008 21:06:44 +0300 (IDT) Date: Tue, 23 Sep 2008 18:06:00 -0000 From: Eli Zaretskii Subject: Re: [RFA/Ada] Implement Ada tasking support In-reply-to: <20080923150717.GF23372@adacore.com> X-012-Sender: halo1@inter.net.il To: Joel Brobecker Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: References: <20080922233209.GE24389@adacore.com> <20080923150717.GF23372@adacore.com> X-IsSubscribed: yes 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/msg00477.txt.bz2 > Date: Tue, 23 Sep 2008 08:07:17 -0700 > From: Joel Brobecker > Cc: gdb-patches@sourceware.org > > > What is the differences, if any, between threads Ada tasks? > > 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? > > Would it make sense to make the existing threads commands to refer to > > Ada tasks, instead of introducing a whole new bunch of commands? > > I don't think so, because I think that Ada tasks and threads are > quite different, and the information displayed for these tasks > has some language-specific parts to it (task state, for instance). We could extend the thread commands to display that additional info if available. Can there ever be more or less than exactly one thread per Ada task? > On the other hand, I see the "thread" support as a layer that > provides information that is language-neutral, but closer to > the underlying system. Both group of commands serve, IMO, a slightly > different purpose. I'm trying to establish whether they are irreconcilable. If they can live together, I'd suggest to merge them.