Re: [RFA/Ada] Implement Ada tasking support

[Joel Brobecker <brobecker at adacore dot com>]

> > 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