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

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

On 07/07/2016 03:00, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:nlj244$43i$1@gioia.aioe.org...
>> On 05/07/2016 23:24, Randy Brukardt wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> ...
>>> 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.
>
> That's actually an advantage, as it greatly decreases the possibility that
> this task will waste time retrying repeatedly.

Note that the alternative guaranties that there is I/O data ready, 
because the task is waked up by an I/O event rater than by timer. It is 
polling which guaranties wasting time.

But the main problem is latencies. In the query-answer scenario it is 
extremely slow to work this way.

>> Bit even if RTS had proper drivers on top of the system ones it would
>> still greatly slower in most case.
>
> Disagree. My experience with Internet servers is that one can and should use
> relatively long delays in I/O without hurting response times.

That is because there is a human user on the other end. For automatic 
systems such latencies are unacceptable. E.g. the initialization cycle 
of EtherCAT distributed clock is 10_000 send packet/receive packet 
cycles. It would never end with 500ms latencies.

>> 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.
>
> Usually, compilers just don't inline in such circumstances, and no one
> really cares unless they happen to look at a machine code listing.

How the compiler can predict it will run out of memory?

>> With mapping tasks to threads you fail at run-time, and there is nothing
>> you can do to prevent that from happening.
>
> Certainly not: the threads are all created at program-startup (5 threads for
> 4 cores, I think),

In that case the compiler must do all system I/O in an asynchronous way 
presenting it as blocking for Ada task. This is what is I would gladly 
have and what will satisfy the OP. The problem is, I suppose, it is not 
what the compiler does.

> No language-defined I/O (or the sockets library, for that matter) would use
> blocking I/O. User-defined code could, of course, call blocking I/O (that
> being the main reason to allow more threads to be added manually). But it
> would be strongly discouraged.

Ah, but that is the point. The tasking model is not allowed to change 
the semantics. This means that if your RTS takes the liberty to use 
single thread for multiple tasks, then it also must convert *all* 
synchronous I/O into asynchronous transparently to the Ada program.

I know that Ada RM does not require it, but I assure you that virtually 
no Ada user will accept anything else.

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