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!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: RFC: Prototype for a user threading library in Ada
Date: Sat, 02 Jul 2016 06:30:47 +0100
Organization: A noiseless patient Spider
Message-ID: <lyd1mwip2w.fsf@pushface.org>
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>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org;
 posting-host="15bacc9237911e76a94be23536470c55";
	logging-data="9900"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18T5FM33/4k4+GFil9bIhMfVtDR/HDy+Pg="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin)
Cancel-Lock: sha1:jzPH4e4ZzA0etQhhd5PwD7hsVmo=
	sha1:fJDtQrJtDzb46Et/xq9XocWUx1E=
Xref: news.eternal-september.org comp.lang.ada:31001
Date: 2016-07-02T06:30:47+01:00
List-Id: <comp.lang.ada>

"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"?