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
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: RFC: Prototype for a user threading library in Ada
Date: Tue, 5 Jul 2016 16:29:12 -0500
Organization: JSA Research & Innovation
Message-ID: <nlh8r5$ph$1@franka.jacob-sparre.dk>
References: 
 <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com><dsim6eF91ubU1@mid.individual.net>
 <nk19hh$o33$1@gioia.aioe.org><d9d7f8f5-8b72-450b-8152-4b6116c6ce2c@googlegroups.com><nkfeqn$nl8$1@franka.jacob-sparre.dk><f4c3e42a-1aa1-4667-83d7-de6f81a8fdd2@googlegroups.com><nknh11$bvg$1@franka.jacob-sparre.dk><1e32c714-34cf-4828-81fc-6b7fd77e4532@googlegroups.com><nl7gbk$41a$1@franka.jacob-sparre.dk>
 <lyd1mwip2w.fsf@pushface.org>
NNTP-Posting-Host: rrsoftware.com
X-Trace: franka.jacob-sparre.dk 1467754149 817 24.196.82.226 (5 Jul 2016
 21:29:09 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Tue, 5 Jul 2016 21:29:09 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Xref: news.eternal-september.org comp.lang.ada:31022
Date: 2016-07-05T16:29:12-05:00
List-Id: <comp.lang.ada>

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyd1mwip2w.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> "Hadrien Grasland" <hadrien.grasland@gmail.com> wrote in message
>
>>>An Ada implementation which would want to make the life of concurrent
>>>programmers easier could do the following things:
>>
>>>1/ Keep the amount of OS threads low (about the amount of CPU cores, a
>>>bit more for I/O), and map tasks to threads in an 1:N fashion.
>>
>> Reasonably easy. (For Windows, stack limitations might be a problem;
>> not a problem on a bare target.)
>
> Most things are a problem on a bare target.
>
> Or do you mean "limitations that Windows places on the _use_ of the
> stack"?

Yes. On Windows (and quite likely other modern OSes, because of the problems 
with C language program bugs causing attack vectors), one can't put any old 
memory address into the stack pointer (the SP register). If you do, you'll 
get an immediate fault. (I discovered this when developing our original Ada 
tasking system - the task stacks were not allowed, which was a problem). 
There probably are ways around this, but I don't know for sure. (If there 
isn't a way around it, it probably would be fatal, one has to switch the 
stacks with the underlying jobs.)

On a bare target, you can write any code you like. Of course, if you get it 
wrong, things go south in a hurry.

                                      Randy.