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
X-Received: by 10.182.60.36 with SMTP id e4mr3525941obr.3.1409258099515;
        Thu, 28 Aug 2014 13:34:59 -0700 (PDT)
X-Received: by 10.50.142.37 with SMTP id rt5mr97269igb.9.1409258099224; Thu,
 28 Aug 2014 13:34:59 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!r2no9420247igi.0!news-out.google.com!ef6ni1325igb.0!nntp.google.com!r2no9420240igi.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Thu, 28 Aug 2014 13:34:58 -0700 (PDT)
In-Reply-To: <uxgn4sadwori$.7fnns7uw9q79$.dlg@40tude.net>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=108.69.213.73;
 posting-account=jTyM8goAAADJ35CkjDrbWN1e-B_W_S9y
NNTP-Posting-Host: 108.69.213.73
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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <1cd027f2-a0e0-4206-b989-4aed2090cde8@googlegroups.com>
Subject: Re: STM32F4 Discovery, communication and libraries
From: embeddedrelatedmike@scriptoriumdesigns.com
Injection-Date: Thu, 28 Aug 2014 20:34:59 +0000
Content-Type: text/plain; charset=ISO-8859-1
Xref: news.eternal-september.org comp.lang.ada:21967
Date: 2014-08-28T13:34:58-07:00
List-Id: <comp.lang.ada>

On Thursday, August 28, 2014 1:09:05 PM UTC-7, Dmitry A. Kazakov wrote:
> Not really. OS is more than tasking, it is also a queueing mechanism, which
> allows waiting for I/O completion in one task without blocking all other
> tasks.
> ......
> You could not implement an equivalent of I/O queueing under the Ravenscar 
> constraints.

Are you saying that a full Ada implementation on bare metal could not implement an equivalent of I/O queueing?

Or are you saying that Ravenscar tasking on bare metal could not implement such queueing?