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: Wed, 6 Jul 2016 15:46:10 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com> NNTP-Posting-Host: vZYCW951TbFitc4GdEwQJg.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 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:31027 Date: 2016-07-06T15:46:10+02:00 List-Id: On 05/07/2016 23:24, Randy Brukardt wrote: > "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 difference is whether this layer is user- or kernel-space. RTS is user-space. Virtualization I/O layer is kernel-space. >>> 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; This is in order of several magnitudes slower because after yield to return back not before next time slot, e.g. timer interrupt. It is no different from polling. Bit even if RTS had proper drivers on top of the system ones it would still greatly slower in most case. >>>> 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. Unless the system limit on the number of physical threads apply. And the situation is reverse. With inlining you may fail at compile time with GNAT when it runts out of memory, and it is recoverable error since you can forbid inlining. With mapping tasks to threads you fail at run-time, and there is nothing you can do to prevent that from happening. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de