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

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

On 05/07/2016 23:24, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:nl859c$hso$1@gioia.aioe.org...
>> On 2016-07-02 06:21, Randy Brukardt wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:nknteq$177m$1@gioia.aioe.org...
>>>> On 2016-06-26 05:09, Randy Brukardt wrote:
>>>>> "Hadrien Grasland" <hadrien.grasland@gmail.com> wrote in message
>>>>> news:f4c3e42a-1aa1-4667-83d7-de6f81a8fdd2@googlegroups.com...
> ...
>>>> Ah, but there is the reason. The OS can switch threads on I/O events. If
>>>> Ada RTS could do this without mapping tasks to threads, fine. Apparently
>>>> it cannot without imposing same or higher overhead OS threads have.
>>>
>>> Dunno; I doubt that it really has been tried. If that was really
>>> impossible,
>>> virtualization wouldn't work either, and there's lots of evidence that
>>> works
>>> fine.
>>
>> But it does not, in this sense. It can handle only virtual devices. In
>> order to access a physical one, you need a software layer. It could be
>> quite difficult for the RTS to follow this path.
>
> Not sure why you say that: every RTS that I've ever seen wraps the I/O
> system in a layer, and indeed the OS itself is another such layer. Hard to
> say why thickening the existing layer a bit more would be harmful.

The difference is whether this layer is user- or kernel-space. RTS is 
user-space. Virtualization I/O layer is kernel-space.

>>> The problem (if there is a problem at all) is fast character-at-a-time I/O -
>>> but that's a bad idea for lots of reasons (it doesn't work very well for
>>> a
>>> sequential program either) so perhaps it wouldn't matter than much.
>>
>> It will make normal I/O slower and RTS larger with compatibility issues.
>
> ??? I can believe that there is *some* program that would be slower, but I'd
> rather the doubt that most programs would be slower.
>
> I'd look at replacing:
>      Read (Handle, Data, Last);
> with something like:
>      loop
>          if Ready (Handle) then
>              Read_Ready_Data (Handle, Data, Last);
>              exit if Last > Data'Last;
>          end if;
>          Yield;
>      end loop;

This is in order of several magnitudes slower because after yield to 
return back not before next time slot, e.g. timer interrupt. It is no 
different from polling.

Bit even if RTS had proper drivers on top of the system ones it would 
still greatly slower in most case.

>>>> Co-routines could offer something in between.
>>>
>>> Sure, but I don't see any need to expose that. Certainly not beyond an
>>> aspect much like "Inline", which is just a suggestion to the compiler to
>>> do
>>> something. It's better to leave implementation decisions (and that's all
>>> this is) to implementations!
>>
>> Well, the difference is that Inline can be safely ignored. Limitation on
>> the task number cannot be.
>
> Same either way - we're "just" talking about performance.

Unless the system limit on the number of physical threads apply. And the 
situation is reverse. With inlining you may fail at compile time with 
GNAT when it runts out of memory, and it is recoverable error since you 
can forbid inlining. With mapping tasks to threads you fail at run-time, 
and there is nothing you can do to prevent that from happening.

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