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,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.31.157.213 with SMTP id g204mr17588655vke.14.1456849903869;
        Tue, 01 Mar 2016 08:31:43 -0800 (PST)
X-Received: by 10.182.144.226 with SMTP id sp2mr225853obb.13.1456849903801;
 Tue, 01 Mar 2016 08:31:43 -0800 (PST)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!peer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!y89no4964778qge.0!news-out.google.com!pn7ni6781igb.0!nntp.google.com!hb3no10428696igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Tue, 1 Mar 2016 08:31:43 -0800 (PST)
In-Reply-To: <nb4e2o$bq8$1@gioia.aioe.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=81.166.54.34;
 posting-account=bXa9kQoAAADQ0LSY80qTyLW4hcbm0Soz
NNTP-Posting-Host: 81.166.54.34
References: <c4f4f07c-679b-4bda-a4f5-8ee689742b3e@googlegroups.com>
 <87k2lmmf5w.fsf@mid.deneb.enyo.de>
 <0e3fb431-ee4b-46ca-b1a5-a78e3245d7f3@googlegroups.com>
 <nb4e2o$bq8$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d961a0d2-2a77-4dc5-b191-0a0285126a66@googlegroups.com>
Subject: Re: pragma Thread_Local_Storage on record?
From: hanslad@gmail.com
Injection-Date: Tue, 01 Mar 2016 16:31:43 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 2400
X-Received-Body-CRC: 3636617676
Xref: news.eternal-september.org comp.lang.ada:29637
Date: 2016-03-01T08:31:43-08:00
List-Id: <comp.lang.ada>

> I don't see how his could be useful for a messages queue which is=20
> normally shared between several tasks rather than owned by any. The=20
> latter looks like a low-level implementation-motivated design.

To explain a bit more: This is just an experiment on implement a small fram=
ework where a set of tasks(one per core) handles a sent of workers that are=
 messaged by other workers (actor style... I think). The reason for using T=
hread_Local_Storage is for performance)I read that somewhere that it could =
be a performance gain using that). The idea is that other workers(handled b=
y other tasks) are sending messages to workers, the workers are at the same=
 time added to the queue of workers, ready for action. I dont know if this =
makes any sense... :-). If this idea has obvious flaws, please feel free to=
 comment.


> A typical solution is Ada.Task_Attributes instantiated with an access=20
> type to the object. The object is allocated on demand (access=20
> dereference by the owner task).

I have considered this, but wanted to try the Thread_Local_Storage pragma f=
or performance reasons.

Thanks.