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!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:21:29 -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 1467433286 3684 24.196.82.226 (2 Jul 2016 04:21:26 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 2 Jul 2016 04:21:26 +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:30999 Date: 2016-07-01T23:21:29-05:00 List-Id: "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... >> .... >> It seems to me that the problem is with the "typical" Ada implementation >> more than with the expressiveness of features, when it comes to highly >> parallel implementations. Mapping tasks directly to OS threads only works >> if >> the number of tasks is small. So if it hurts when you do that, then DON'T >> DO >> THAT!! :-) >> >> There's no reason for any particular mapping of Ada tasks to OS threads. > > 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. 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. > 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! Randy.