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,LOTS_OF_MONEY 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!nntp-feed.chiark.greenend.org.uk!ewrotcd!reality.xs3.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: Tue, 5 Jul 2016 16:24:02 -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 1467753839 802 24.196.82.226 (5 Jul 2016 21:23:59 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 5 Jul 2016 21:23:59 +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:31021 Date: 2016-07-05T16:24:02-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:nl859c$hso$1@gioia.aioe.org... > On 2016-07-02 06:21, Randy Brukardt wrote: >> "Dmitry A. Kazakov" wrote in message >> news:nknteq$177m$1@gioia.aioe.org... >>> On 2016-06-26 05:09, Randy Brukardt wrote: >>>> "Hadrien Grasland" wrote in message >>>> news:f4c3e42a-1aa1-4667-83d7-de6f81a8fdd2@googlegroups.com... ... >>> Ah, but there is the reason. The OS can switch threads on I/O events. If >>> Ada RTS could do this without mapping tasks to threads, fine. Apparently >>> it cannot without imposing same or higher overhead OS threads have. >> >> Dunno; I doubt that it really has been tried. If that was really >> impossible, >> virtualization wouldn't work either, and there's lots of evidence that >> works >> fine. > > But it does not, in this sense. It can handle only virtual devices. In > order to access a physical one, you need a software layer. It could be > quite difficult for the RTS to follow this path. Not sure why you say that: every RTS that I've ever seen wraps the I/O system in a layer, and indeed the OS itself is another such layer. Hard to say why thickening the existing layer a bit more would be harmful. >> The problem (if there is a problem at all) is fast character-at-a-time >> I/O - >> but that's a bad idea for lots of reasons (it doesn't work very well for >> a >> sequential program either) so perhaps it wouldn't matter than much. > > It will make normal I/O slower and RTS larger with compatibility issues. ??? I can believe that there is *some* program that would be slower, but I'd rather the doubt that most programs would be slower. I'd look at replacing: Read (Handle, Data, Last); with something like: loop if Ready (Handle) then Read_Ready_Data (Handle, Data, Last); exit if Last > Data'Last; end if; Yield; end loop; The expensive operation would only be called if the I/O isn't ready. And in that case, this task has to wait anyway, so the performance of Yield really doesn't matter. (It is unlikely to be significant if Read takes 49 or 50 milliseconds.) So the only possible issue is the underlying cost of "Ready". I'd expect that to be cheap (especially if the I/O system is buffering I/O anyway), but one would need to try it in real conditions to be sure. I suppose there is a downside to this scheme, in that user-written I/O (that is, directly to devices) also has to be written this way, but that may be a small price to pay. >>> Co-routines could offer something in between. >> >> Sure, but I don't see any need to expose that. Certainly not beyond an >> aspect much like "Inline", which is just a suggestion to the compiler to >> do >> something. It's better to leave implementation decisions (and that's all >> this is) to implementations! > > Well, the difference is that Inline can be safely ignored. Limitation on > the task number cannot be. Same either way - we're "just" talking about performance. (The program will work in either case if the advice is ignored.) One has to be careful about exposing too much of the mechanism specifically for performance, as that almost always harms abstraction. And, as I pointed out before, performance is never portable. To the extent that one depends on performance, it has to be retested and retuned on every change (architecture, compiler, even major compiler version). Randy.