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!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: RFC: Prototype for a user threading library in Ada Date: Fri, 1 Jul 2016 23:13:30 -0500 Organization: JSA Research & Innovation Message-ID: References: <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1467432808 3517 24.196.82.226 (2 Jul 2016 04:13:28 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 2 Jul 2016 04:13:28 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:30998 Date: 2016-07-01T23:13:30-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:nknrui$15bn$1@gioia.aioe.org... > On 2016-06-26 05:21, Randy Brukardt wrote: >> "Dmitry A. Kazakov" 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;" > > I didn't. With yielding processor it would no more be busy-waiting. Nothing wrong with busy-waiting; it gets a bad rep. >> 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). > > Not really. The whole point is that in the imaginary case under > consideration you don't need a timer event in order to wake Write up. I > presume that there is an I/O event that tells this: > > 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; > Output_Buffer.Wait_For_State (Not_Full); -- A PO's entry call > end loop; > end Write; > > Now the code is exactly same for a task and a co-routine. What is left is > the overhead of thread scheduling to remove. I agree this is better than using Yield. If this sort of formulation is possible, it ought to be used. And then there is no problem -- there's no thread scheduling overhead with Janus/Ada, 'cause there are no threads! :-) Seriously, I'm thinking that thread scheduling overhead could be reduced/eliminated by the task supervisor, and thus there's no real problem with writing Ada tasks this way -- except of course that existing implementations don't try to do this sort of optimization. Or I could just be mad. :-) [When it comes to tasking, I know just enough to be dangerous. ;-)] Randy.