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:nkl8bm$19q7$1@gioia.aioe.org...
> On 2016-06-24 02:38, rieachus@comcast.net wrote:
>> I don't get it.  If this is your "motivation":
>>
>>> The motivation is a two-liner. Let you have some consumer of data:
>>>
>>>    procedure Write (Buffer : String; Last : out Integer);
>>>
>>> It may take less than the whole string when called, but will take more
>>> data later. So, the parameter Last. Now you want to write a program in a
>>> *normal* way:
>>>
>>>    Write ("This");
>>>    Write ("That");
>>>
>>> That's it.
>>
>> You may want to make your Last parameter in or in out, but that's a 
>> detail.
>
> It is not a detail. The caller of Write does not know how much data the 
> transport layer is ready to accept. That is the nature of non-blocking 
> I/O. Write takes as much data it can and tells through Last where the 
> caller must continue *later*.
>
> A blocking busy-waiting wrapper looks this way:
>
>    procedure Write (Buffer : String) is
>       First : Integer := Buffer'First;
>       Last  : Integer;
>    begin
>       loop
>          Write (Buffer (First..Buffer'Last), Last);
>          exit when Last = Buffer'Last;
>          First := Last + 1;
>       end loop;
>    end Write;

You forgot the "delay 0.0;" (or "yield;" as Ada 2012 aliased it):

    procedure Write (Buffer : String) is
       First : Integer := Buffer'First;
       Last  : Integer;
    begin
       loop
          Write (Buffer (First..Buffer'Last), Last);
          exit when Last = Buffer'Last;
          First := Last + 1;
          delay 0.0;
       end loop;
    end Write;

The delay gives up the processor so that other tasks can run. It's how most 
I/O works in Janus/Ada. (Note that if you know something about the latencies 
of Write, you can use a better value than "0.0", so you don't try again 
until you're pretty sure the system is ready. For instance, for socket I/O 
we typically use 0.01, so the program isn't churning and doing nothing. 
[Although we usually use a system of increasing delays, so that if it is 
ready almost immediately, we're continuing to write, else we're waiting 
longer and not wasting time trying something that's unlikely to be ready.])

That, combined with proper tasking runtimes, would seem to provide better 
results than doing all one thing (task = thread) or all othe ther (some 
fancy coroutine system).

                                      Randy.