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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: 
 buffer2.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!news.swapon.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "G.B." <bauhaus@futureapps.invalid>
Newsgroups: comp.lang.ada
Subject: Re: STM32F4 Discovery, communication and libraries
Date: Mon, 01 Sep 2014 19:21:49 +0200
Organization: A noiseless patient Spider
Message-ID: <lu29ve$lq5$1@dont-email.me>
References: <60a42dc6-d8d0-4432-ae5a-86de18b82840@googlegroups.com>
 <5kkrv9hejn2qhdckkeo8lidkbh3bkme1gn@4ax.com>
 <5b91313c-acf9-4a6e-b157-6ba7c8021567@googlegroups.com>
 <ru1tv9p9g8gtd7aijug3j2eojdpdgvhihk@4ax.com>
 <0513ad07-6fbe-463a-be6f-097cd5113f52@googlegroups.com>
 <e8yq8rtj1pcm$.glzqqjd7ulsi.dlg@40tude.net>
 <4f1ec65a-d66a-40bf-a0d6-278fde206e70@googlegroups.com>
 <uxgn4sadwori$.7fnns7uw9q79$.dlg@40tude.net>
 <c69kifFfr6sU1@mid.individual.net>
 <1cjwzr30b24xy.11kpydntxhfo5$.dlg@40tude.net>
 <c6bo5nF23tiU1@mid.individual.net>
 <1xrcksk78afho$.xz6vgakq9o4t.dlg@40tude.net>
 <c6h8ieFfss4U1@mid.individual.net>
 <wq3x8ean0f5z$.em02okqv4iv8$.dlg@40tude.net>
Reply-To: nonlegitur@futureapps.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 1 Sep 2014 17:21:50 +0000 (UTC)
Injection-Info: mx05.eternal-september.org;
 posting-host="b96887e80893c84a90c3007226ca0d1c";
 logging-data="22341"; mail-complaints-to="abuse@eternal-september.org";
 posting-account="U2FsdGVkX18jcrfKqCtMy9ElDYlqbA3DYla75xjBl5Y="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
In-Reply-To: <wq3x8ean0f5z$.em02okqv4iv8$.dlg@40tude.net>
Cancel-Lock: sha1:Sj4/fGIRw1wqtUcDOgU4bnjftD0=
Xref: number.nntp.dca.giganews.com comp.lang.ada:188779
Date: 2014-09-01T19:21:49+02:00
List-Id: <comp.lang.ada>

On 01.09.14 18:42, Dmitry A. Kazakov wrote:
> I don't know how much overhead it will be (I was trying to reduce
> number of protected actions per event), but it looks ugly and overly
> complicated.

By design, and of necessity, I think, Ravenscar tasking looks ugly
and complicated for a reasons, even if not used for something close
to emulating the full Ada run-time support for tasking and I/O:
everything that you'd think is normally implied by the language,
such as some queues, requires manifestation.

Also, maybe you'd only think that this and that is implied by the
language: now what about bugs in programs using full Ada tasking?
Are they easier or more difficult to find when much more features
of concurrency are stated explicitly in Ravenscar programs?

Will a small board made for the ubiquitous, penniless underlings
working in cost-optimized production warrant a full Ada run-time?
Why, if systems are not meant to be flexible?
And what will be its overhead?