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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: RFC: Prototype for a user threading library in Ada Date: Sat, 2 Jul 2016 12:33:05 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com> NNTP-Posting-Host: w/2xSGckQeJEFvqsQFNodA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 X-Notice: Filtered by postfilter v. 0.8.2 X-Mozilla-News-Host: news://news.aioe.org Xref: news.eternal-september.org comp.lang.ada:31003 Date: 2016-07-02T12:33:05+02:00 List-Id: 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... >>> .... >>> 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. 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. > 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. >> 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de