Re: RFC: Prototype for a user threading library in Ada

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 08/07/2016 01:43, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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