From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: RFC: Prototype for a user threading library in Ada
Date: Sat, 18 Jun 2016 10:47:47 +0200
Organization: Aioe.org NNTP Server
Message-ID: <nk31ru$10pb$1@gioia.aioe.org>
References: <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com>
 <dsim6eF91ubU1@mid.individual.net> <nk19hh$o33$1@gioia.aioe.org>
 <d9d7f8f5-8b72-450b-8152-4b6116c6ce2c@googlegroups.com>
NNTP-Posting-Host: w/2xSGckQeJEFvqsQFNodA.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
X-Notice: Filtered by postfilter v. 0.8.2
Xref: news.eternal-september.org comp.lang.ada:30775
Date: 2016-06-18T10:47:47+02:00
List-Id: <comp.lang.ada>

On 2016-06-18 10:16, Hadrien Grasland wrote:

> In addition to the benefits you mention, I will also add that a
> language-level implementation can potentially trap blocking system calls
> and substitute them with task switches for latency hiding. It will also
> get wide support from the standard library instead of requiring many
> custom primitives an wrapper, which means more development time to focus
> on the core concurrency model.

It looks like too much burden on the implementation if possible at all.

But certainly, yes, entry calls must be aware of the context when made 
from a co-routine.

Regarding system calls, surely there must be a way to make non-blocking 
system calls looking as if they were blocking. Otherwise the whole idea 
would make no sense at all.

I don't care much about wrappers, since they can be easily done:

    procedure Read (Buffer : in out Stream_Element_Array) is
       Last : Stream_Element_Offset;
    begin
       loop
          Read (File, Buffer, Last); -- Non-blocking
          exit when Last = Buffer'Last;
          accept Reschedule; -- Give up until next time
       end loop;
    end Read;

The co-routine body would simply call Read and get all buffer filled.

A bigger problem is "releasing" a co-routine waiting for an asynchronous 
system call completion without polling. One solution could be events 
(protected objects) associated with the state of the non-blocking exchange:

    procedure Read (Buffer : in out Stream_Element_Array) is
       Last : Stream_Element_Offset;
    begin
       loop
          Read (File, Buffer, Last);
          exit when Last = Buffer'Last;
          File.IO_Event.Signaled; -- "Entry call"
       end loop;
    end Read;

> However, I think that as it stands, we are just about as likely to
> see  it happening in Ada as we are to get lambdas and first-class function
> objects.

Yes, it is difficult to convince. But co-routines do not look like much 
a change since all syntax necessary is basically there. It is semantics 
of entry calls and accept statements which must be attuned.

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