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

The expensive operation would only be called if the I/O isn't ready. And in 
that case, this task has to wait anyway, so the performance of Yield really 
doesn't matter. (It is unlikely to be significant if Read takes 49 or 50 
milliseconds.) So the only possible issue is the underlying cost of "Ready". 
I'd expect that to be cheap (especially if the I/O system is buffering I/O 
anyway), but one would need to try it in real conditions to be sure.

I suppose there is a downside to this scheme, in that user-written I/O (that 
is, directly to devices) also has to be written this way, but that may be a 
small price to pay.

>>> 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. (The program will 
work in either case if the advice is ignored.) One has to be careful about 
exposing too much of the mechanism specifically for performance, as that 
almost always harms abstraction.

And, as I pointed out before, performance is never portable. To the extent 
that one depends on performance, it has to be retested and retuned on every 
change (architecture, compiler, even major compiler version).

                               Randy.