From owner-freebsd-hackers  Mon May 19 09:34:10 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id JAA01435
          for hackers-outgoing; Mon, 19 May 1997 09:34:10 -0700 (PDT)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA01408
          for <hackers@FreeBSD.ORG>; Mon, 19 May 1997 09:34:02 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA24291; Mon, 19 May 1997 09:26:03 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199705191626.JAA24291@phaeton.artisoft.com>
Subject: Re: GNAT-pthreads integration bugs/questions
To: deischen@iworks.InterWorks.org (Daniel M. Eischen)
Date: Mon, 19 May 1997 09:26:03 -0700 (MST)
Cc: hackers@FreeBSD.ORG, terry@lambert.org
In-Reply-To: <199705190341.WAA26464@iworks.InterWorks.org> from "Daniel M. Eischen" at May 18, 97 10:41:25 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> Maybe I'm missing something here ;-)  In the GNAT runtime, I need to
> be able to retrieve a pointer to a structure (Ada Task Control Block)
> based soley on the PID (assuming we're using rfork).  The PID is all
> we know, and we must be able to find the ATCB for this process.  The
> structures can be in shared data, but I still have to perform some
> sort of lookup/search to find the ATCB for a process ID.

This implies that the Ada Tasks are not anonymous "work to do" model
threads.

This bodes poorly for SMP scalability, and implies some measure of
CPU starvation even in the UP case.  8-(.


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.