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.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!inmet!stt
From: stt@inmet.inmet.com
Newsgroups: comp.lang.ada
Subject: Re: Fixed Frame Scheduling
Message-ID: <20600025@inmet>
Date: 4 Dec 89 15:46:00 GMT
References: <23041@gryphon.COM>
Nf-ID: #R:gryphon.COM:23041:inmet:20600025:000:932
Nf-From: inmet.inmet.com!stt    Dec  4 10:46:00 1989
List-Id: <comp.lang.ada>


You haven't given enough information on "fixed-frame scheduling"
for me to give you a complete answer.  However, most
Ada tasking issues having to do with getting control
back to a caller involve allocating a "buffer task" of
some sort, and passing control to the caller via the buffer
task.  The initial call returns immediately, with an
access to a buffer task returned.  The caller then
calls an entry of the buffer task, remaining suspended
until the buffer task accepts it.  At a later time, 
the acceptor calls a different entry of the buffer
task which allows the buffer task to accept the
entry upon which the original caller is suspended.
In this way, the acceptor can control the activity
of the original caller without having to be itself
suspended as long as is the caller.

I don't really see how this would solve your
scheduling problem, but maybe you do... :-}

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138