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,FREEMAIL_FROM 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: Victor Porton Newsgroups: comp.lang.ada Subject: Re: Feature suggestion: different task schedules Date: Sun, 23 Jul 2017 15:31:12 +0300 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: qrWnZLr+FAc2xoElQM2hng.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: abuse@aioe.org User-Agent: KNode/4.14.10 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:47498 Date: 2017-07-23T15:31:12+03:00 List-Id: Dmitry A. Kazakov wrote: > On 18/07/2017 22:09, Randy Brukardt wrote: >> "Dmitry A. Kazakov" wrote in message >> news:okkcgc$1m31$1@gioia.aioe.org... >>> On 18/07/2017 02:09, Randy Brukardt wrote: >> ... >>>> And most important of all -- what problem >>>> needs to be solved. >>> >>> A co-routine with task interface lacking task overhead. >> >> I hate to sound like a broken record, but that's a solution, not a >> problem. One would need to explain what problem(s) can't be reasonably >> solved with the existing features of Ada that could be solved with a >> co-routine. (And a purely performance argument is by far the weakest >> IMHO; very few programs are really performance bound, and most of those >> would value more tasking.) > > It is not performance argument. It is it the first line design argument > (control flow inversion) as I explained in another post. > > I admit that I don't understand the OP proposal. It is not sufficiently > described and scheduling is not single issue here. Not in the cases I > have in mind. > > A task based solution is non-starter for two reasons. > > One is that it is not composable. I expect a co-routine proposal to > offer a possibility to implement stacked layered protocols. I don't see > how that would be possible on task basis. A protocol implementation may > not be a task object. I don't understand why it is not composable. A task may call another tasks. Tasks may even call each others in a cycle. However I think, we may have some sort of problem about specifying something in hypothetical Ada2020 what is similar to `yield from` in Python. It seems that for this we need to introduce something like "multi" accept statement, but I did not yet thought about this. > Another reason is design and OS constraints. Protocols must be handled > by worker tasks. Number of tasks <<< number of connections, e.g. number > of sockets. -- Victor Porton - http://portonvictor.org