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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Advice, tasking and hardware Date: Fri, 27 May 2016 22:27:21 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <25c43463-47ca-4021-82ee-299e6a075faa@googlegroups.com> NNTP-Posting-Host: g5mwItfuOGVKEwkuGFLFAw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:30495 Date: 2016-05-27T22:27:21+02:00 List-Id: 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. >> 6. Task entries cannot return unconstrained objects. > > This can be worked around: > We can add to the previous task the following: > Entry Data( Item : out Natural ); > Entry Data( Item : out String ); This is a very low-level and very fragile design. Consider ensuring that nothing comes between querying the length and the body that could change the string. You start doing that with entry barriers risking running into a deadlock. Then consider a possibility that the caller of a get-length request dies prematurely, or that another task steals the string body and so on. Note that the "discussion" started around the claim that design based on semaphore is more low-level than one based on monitor (the task serves as a monitor). (There was a reason why protected objects were introduced in Ada 95) P.S. The Ada-way of returning string is this: entry Get_Text (Text : in out String; Last : out Integer); I am using a bit more general: entry Get_Text (Text : in out String; Pointer : in out Integer); -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de