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

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

"Hadrien Grasland" <hadrien.grasland@gmail.com> wrote in message 
news:d9d7f8f5-8b72-450b-8152-4b6116c6ce2c@googlegroups.com...
...
>I agree that implementation support for coroutines would be extremely 
>valuable, if it
>were available at the language level (as in Python, C#, Go...) or even in 
>specific
>implementations (as in Visual C++).

Coincidentally, we just spent quite substantial portion of the most recent 
ARG meeting discussing this. (See AI12-0197-1; there are proposed 
alternatives as well but those won't get posted for a few weeks - probably 
along with the minutes.)

The problem with such proposals is that they are quite expensive to 
implement, and they don't seem to buy that much above the existing Ada 
tasking model. [Especially as the proposal explicitly does not support any 
concurrency; one has to use POs/atomics in the normal way if concurrency is 
needed.] (After all, if you really want coroutines in Ada, just use 
Janus/Ada and regular tasks as it implements all tasks that way. :-)

The problem with the Janus/Ada implementation is the inability to use 
threads to implement that; that's fixable but I'd need a customer to help 
support the work. (I'd use a scheme internal to the task supervisor similar 
to your "events" rather than trying to assign tasks to threads.)

...
>However, I think that as it stands, we are just about as likely to see it 
>happening in Ada as we are to get lambdas ...

We also talked about limited lambdas in Pisa: see AI12-0190-1. So you're 
obviously right. ;-)

---

The problem I have with the library approach (and the coroutines and the 
like intended to support it) is that it does seem to solve any problems. I 
understand why such approaches get used in languages that don't have a real 
tasking model, but Ada hasn't had that problem since day 1. And the reasons 
that writing tasking code in Ada is too hard aren't getting addressed by 
these schemes (that is, race conditions, deadlocks [especially data 
deadlocks], and the like).

I'd prefer to concentrate on language features that make it as easy to write 
(restricted and correct) parallel code as it is to write sequential code. I 
don't see how libraries or coroutines or lambdas are getting us any closer 
to that.

I'd like to understand better the motivations for these features, so if you 
(or anyone else) wants to try to explain them to me, feel free. (But keep in 
mind that I tend to be hard to convince of anything these days, so don't 
bother if you're going to give up easily. ;-)

                                            Randy.