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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.28.168.69 with SMTP id r66mr318333wme.1.1466241423649; Sat, 18 Jun 2016 02:17:03 -0700 (PDT) X-Received: by 10.157.63.245 with SMTP id i50mr211579ote.9.1466241423484; Sat, 18 Jun 2016 02:17:03 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!goblin1!goblin.stu.neva.ru!oe3no3736487lbb.1!news-out.google.com!f5ni1890lbb.0!nntp.google.com!w10no1934496lbo.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 18 Jun 2016 02:17:03 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=78.192.88.225; posting-account=21X1fwoAAABfSGdxRzzAXr3Ux_KE3tHr NNTP-Posting-Host: 78.192.88.225 References: <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <5b542d7c-e10e-4e3a-b98a-2b538bec0670@googlegroups.com> Subject: Re: RFC: Prototype for a user threading library in Ada From: Hadrien Grasland Injection-Date: Sat, 18 Jun 2016 09:17:03 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:30776 Date: 2016-06-18T02:17:03-07:00 List-Id: Le samedi 18 juin 2016 10:48:00 UTC+2, Dmitry A. Kazakov a =C3=A9crit=C2=A0= : > > Regarding system calls, surely there must be a way to make non-blocking= =20 > system calls looking as if they were blocking. Otherwise the whole idea= =20 > would make no sense at all. > > I don't care much about wrappers, since they can be easily done: >=20 > procedure Read (Buffer : in out Stream_Element_Array) is > Last : Stream_Element_Offset; > begin > loop > Read (File, Buffer, Last); -- Non-blocking > exit when Last =3D Buffer'Last; > accept Reschedule; -- Give up until next time > end loop; > end Read; >=20 > The co-routine body would simply call Read and get all buffer filled. >=20 > A bigger problem is "releasing" a co-routine waiting for an asynchronous= =20 > system call completion without polling. One solution could be events=20 > (protected objects) associated with the state of the non-blocking exchang= e: >=20 > procedure Read (Buffer : in out Stream_Element_Array) is > Last : Stream_Element_Offset; > begin > loop > Read (File, Buffer, Last); > exit when Last =3D 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 I= O 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 o= f 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 noti= on 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 w= ays these can go wrong is all but infinite, however there has to be a bette= r synchronization primitive for this kind of progressive evolution.