Re: RFC: Prototype for a user threading library in Ada

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:nl84rj$h70$1@gioia.aioe.org...
> On 2016-07-02 06:13, Randy Brukardt wrote:
>
>> Seriously, I'm thinking that thread scheduling overhead could be
>> reduced/eliminated by the task supervisor, and thus there's no real 
>> problem
>> with writing Ada tasks this way -- except of course that existing
>> implementations don't try to do this sort of optimization.
>
> There could be OS limitations on the number of threads a process may have.

It would be weird if one couldn't have as many threads as there are cores. 
(And if not, then one has to have more processes rather than more threads.)

> I was thinking about "user-scheduled" tasks, which are not scheduled at 
> all. Some user task explicitly releases one task from the pool and gets 
> control back when that task calls to an entry.

Yes, that's how all tasks work in Janus/Ada.

> The important point I believe is preemption. "User-scheduled" tasks would 
> not be required to be preemptive.

Nothing in the core language of Ada requires tasks to be pre-emptive. I 
believe any such requirement is a mistake, one that the runtime I'm talking 
about isn't going to make. (I.e., the Janus/Ada runtime doesn't support 
preemption, and that's very unlikely to change even when multiple threads 
get involved.) Such an implementation can't meet some of the default 
requirements of Annex D; that's another reason for an aspect to be involved 
(to say that Annex D doesn't apply). But of course there's no requirement to 
implement any SNA (such as Annex D) to implement Ada. There's a reason these 
things are separate!

                              Randy.