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!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: RFC: Prototype for a user threading library in Ada Date: Wed, 22 Jun 2016 20:42:48 -0500 Organization: JSA Research & Innovation Message-ID: References: <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1466646167 24232 24.196.82.226 (23 Jun 2016 01:42:47 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 23 Jun 2016 01:42:47 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:30884 Date: 2016-06-22T20:42:48-05:00 List-Id: "Hadrien Grasland" 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.