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!gegeweb.org!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Advice, tasking and hardware Date: Fri, 27 May 2016 17:27:12 -0500 Organization: JSA Research & Innovation Message-ID: References: <25c43463-47ca-4021-82ee-299e6a075faa@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1464388033 7158 24.196.82.226 (27 May 2016 22:27:13 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 27 May 2016 22:27:13 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:30497 Date: 2016-05-27T17:27:12-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:niaaji$1nar$1@gioia.aioe.org... > On 2016-05-27 21:13, Shark8 wrote: >> On Friday, May 27, 2016 at 1:50:50 AM UTC-6, Dmitry A. Kazakov wrote: >>> 5. Tasks entries have parameter passing problems. If you don't handle >>> everything in the rendezvous in order to release the caller as soon as >>> possible, you need to copy parameters and store them locally. The design >>> of the select statement prevents doing this in a structured way. E.g. >>> >>> select >>> accept String_Call (Text : String) do >>> Local_Text := Text; -- Accept scope >>> end; >>> declare -- Handler's scope >>> Local_Text : String -- This does not work! >>> begin >>> -- Process Local_Text >>> end; >>> or accept ... >> >> Pretty much a non-problem in Ada 2012: >> >> package Example is >> >> Task Text_IO is >> Entry Get( Data : String ); >> Entry Put; >> Entry Done; >> End Text_IO; >> >> end Example; >> >> package body Example is >> >> Task Body Text_IO is >> Package String_Holder is new Ada.Containers.Indefinite_Holders( >> Element_Type => String ); > > That is no solution. You still have to move entry-specific local data to > the task-wide scope, which was the main point of being unstructured. > > And you certainly don't want pool-allocated stuff in drivers. > Finally, this is no different from Unbounded_String. Sure, if the only unconstrained type you ever use is a String. The Indefinite_Holders solution works for any unconstrained type, not just String. And no one (I hope!) is putting tasks in drivers in the first place; one wants as little as possible in OS drivers, because they necessarily are outside of the control of the OS (written without the standards used for the OS, etc.) The caller of the driver needs to manage concurrency. So how one writes tasks isn't particularly relevant to writing drivers. (Whether or not the OS should avoid pool allocation is a different question altogether...) Aside: I get the feeling that the term "drivers" has been totally corrupted in recent systems, including all kinds of higher-level junk that belongs to the OS. So we might be talking about different things. Randy.