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

[Hadrien Grasland <hadrien.grasland@gmail.com>]

Le samedi 18 juin 2016 10:48:00 UTC+2, Dmitry A. Kazakov a écrit :
>
> 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;

Yes, if you control the wrapper responsible for making the "blocking" call, handling caller release is quite easy. You simply launch the nonblocking IO asynchronously, and have the caller task wait for the corresponding event object. When the IO is done, the event is fired, and the "blocked" caller is rescheduled.

But nonblocking IO is something I want to study more during the evolution of this library, as I think it is something which stresses the limits of the event model I propose. Single-shot events are a good fit when a clear notion of task completion exists, but they are less suitable when dealing with continuous processes such as streaming IO.

I do not want to go in the direction of reusable events, as the amount of ways these can go wrong is all but infinite, however there has to be a better synchronization primitive for this kind of progressive evolution.