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

["Randy Brukardt" <randy@rrsoftware.com>]

"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? Inlining is just the duplication of some internal data 
structure; if you run out of memory doing that duplication, you just forget 
the operation and back out any changes. Our optimizer works that way in the 
unlikely case that it runs out of memory (at least it is supposed to; it's 
hard to test because it's hard to make the necessary conditions).

Ada programs at least have a chance of recovering from an out-of-memory 
situation, and it certainly makes sense to use that here. (One could also 
precheck that enough memory is available, but of course that's never certain 
to be true when you actually do the allocation, so you still need the 
fallback code.)

>>> With mapping tasks to threads you fail at run-time, and there is nothing
>>> you can do to prevent that from happening.
>>
>> Certainly not: the threads are all created at program-startup (5 threads 
>> for
>> 4 cores, I think),
>
> In that case the compiler must do all system I/O in an asynchronous way 
> presenting it as blocking for Ada task. This is what is I would gladly 
> have and what will satisfy the OP. The problem is, I suppose, it is not 
> what the compiler does.
>
>> No language-defined I/O (or the sockets library, for that matter) would 
>> use
>> blocking I/O. User-defined code could, of course, call blocking I/O (that
>> being the main reason to allow more threads to be added manually). But it
>> would be strongly discouraged.
>
> 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).

> 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.

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.)

                             Randy.