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=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,1d4203bfa2644439
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.180.83.101 with SMTP id p5mr198632wiy.0.1355383210092;
        Wed, 12 Dec 2012 23:20:10 -0800 (PST)
Path: 
 i11ni145469wiw.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!195.62.100.242.MISMATCH!newsfeed.kamp.net!newsfeed.kamp.net!newsfeed.straub-nv.de!nuzba.szn.dk!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: Jacob Sparre Andersen <sparre@nbi.dk>
Newsgroups: comp.lang.ada
Subject: Re: Task with access to itself?
Date: Thu, 13 Dec 2012 08:20:05 +0100
Organization: Jacob Sparre Andersen Research & Innovation
Message-ID: <878v921kre.fsf@adaheads.sparre-andersen.dk>
References: <8738zk7gge.fsf@adaheads.sparre-andersen.dk>
	<k9nuct$f4n$1@dont-email.me>
	<87ehiwygv1.fsf@adaheads.sparre-andersen.dk>
	<ka85lk$8pe$1@dont-email.me>
	<87k3snj9wc.fsf@adaheads.sparre-andersen.dk>
	<kaarus$die$1@dont-email.me>
NNTP-Posting-Host: 91.194.37.55
Mime-Version: 1.0
X-Trace: munin.nbi.dk 1355383208 6908 91.194.37.55 (13 Dec 2012 07:20:08 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Thu, 13 Dec 2012 07:20:08 +0000 (UTC)
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
Cancel-Lock: sha1:RQcMYKbMmFuspWsHw0TuEVkBH+c=
Content-Type: text/plain; charset=us-ascii
Date: 2012-12-13T08:20:05+01:00
List-Id: <comp.lang.ada>

Jeffrey Carter wrote:
> Jacob Sparre Andersen wrote:

>> Because I prefer to activate the most recently used task first, as it
>> is likely to be the one which is "closest" to a CPU (i.e. least
>> likely to be swapped out to disk).
>
> You're not talking about activation;

No, not in the Ada sense of the term.  Sorry for the confusion.

> you're talking about which task handles the next job. Our scheme does
> the opposite of what you want; the task that handles the next job is
> usually the one that has been idle the longest.

That is also what I would expect from a "typical" Ada run-time.

Greetings,

Jacob
-- 
"The universe isn't for the likes of me to understand. I only work here."