Re: Advice, tasking and hardware

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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.