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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 05/07/2016 23:53, Randy Brukardt wrote:
> "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 strongly disagree, especially when we are talking about tasks. A task 
is a logical entity independent on the host architecture. Then if the OS 
supports non-busy I/O waiting, and most OSes do, it makes a lot of sense 
to have many threads, most of which blocked waiting for something.

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

Of course, the problem is to be able to mix both types of tasks being 
able to hint the compiler which one it should take.

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

Some applications rely on time sharing and most do on close to instant 
switching to a task of higher priority.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de