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!news.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: Fri, 8 Jul 2016 10:23:53 +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:31038 Date: 2016-07-08T10:23:53+02:00 List-Id: On 08/07/2016 01:43, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:nlloma$1vh8$1@gioia.aioe.org... >> On 07/07/2016 03:00, Randy Brukardt wrote: > ... >>> Usually, compilers just don't inline in such circumstances, and no one >>> really cares unless they happen to look at a machine code listing. >> >> How the compiler can predict it will run out of memory? > > Why would it have to? No idea, it is a huge problem with GNAT. I am not sure if that happens because of inlining or because of cross-references it builds, but GNAT promptly runs out of 2GB memory when compiling large projects. The workaround I know is to reduce the number of with clauses per unit. It is not enough to with clauses move them to another packet "with" that one. The distance must be at least 2 units away. It is quite annoying. >> Ah, but that is the point. The tasking model is not allowed to change the >> semantics. This means that if your RTS takes the liberty to use single >> thread for multiple tasks, then it also must convert *all* synchronous I/O >> into asynchronous transparently to the Ada program. > > But of course it's impossible for the compiler to change user-written code. > If you do a direct interface to some C API, there is no way the compiler > could change that (nor would it be a good idea to do so). You were talking about a virtualization layer. So theoretically it could be possible. But practically it is a non-starter, that is why user-scheduled tasks must be programmer's choice and not mere optimization as you suggested. >> I know that Ada RM does not require it, but I assure you that virtually no >> Ada user will accept anything else. > > That's demonstratably false, since Janus/Ada has always worked this way, and > we've had far more than than zero customers over the years. You didn't tell them? (:-)) > In any case, there would be no issue unless the programmer writes their own > I/O; using anything we provide (language-defined or implementation-defined) > would work. I'd think the vast majority of Ada programs would use Stream_IO > compared to something of their own design. (Sockets is the big issue, since > the language doesn't have it, but portable libraries can easily be made to > do the right thing.) Yes, a numeric application need none of this stuff. But new shiny things in Ada appear in embedded and distributed systems moving some real hardware. These are the areas where problems arise. And as Gnoga will gain its popularity the same questions will appear for fat server applications. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de