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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no 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: =?UTF-8?B?QmrDtnJuIEx1bmRpbg==?= <b.f.lundin@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: =?UTF-8?B?R05BVMKgYW5kIFRhc2tsZXRz?=
Date: Wed, 17 Dec 2014 23:52:36 +0100
Organization: A noiseless patient Spider
Message-ID: <m6t1f1$5th$1@dont-email.me>
References: <455d0987-734a-4505-bb39-37bfd1a2cc6b@googlegroups.com>
 <XKOjw.764819$JH1.280080@fx08.iad>
 <f9828477-a98e-4795-803d-5926aa7a1fdb@googlegroups.com>
 <cfe7hnFaj8oU1@mid.individual.net> <m6susq$5pq$1@loke.gir.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 17 Dec 2014 22:52:17 +0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="f6df73911ff23addd22916dd4a43b2a5";
	logging-data="6065"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1/C7/zQA57e/wKJ/CJJV04R"
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Icedove/31.2.0
In-Reply-To: <m6susq$5pq$1@loke.gir.dk>
Cancel-Lock: sha1:j6LnmrQ1Vyh7krunHmjtCgHoUBc=
Xref: news.eternal-september.org comp.lang.ada:24081
Date: 2014-12-17T23:52:36+01:00
List-Id: <comp.lang.ada>

On 2014-12-17 23:08, Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 


> 
>> As I remember, the user-level thread solution in GNAT had the drawback 
>> that if one thread blocked on an OS call, the whole program was blocked.
> 
> True, but that's not a real problem in most software (that has to respond in 
> human timescales - if you need microsecond response times, forget 
> Janus/Ada!). 

That kind of rules out a common pattern we have in communication
processes.
Usually we set up a socket, globally, in a package body.

One task does a blocking select() - thus hanging on it - for say 5-30 s.
When a message arrives, it
* logs it in a database table
* acks back to the sender, meaning we own the message now
* Notifies another process to treat the message
* goes back to blocking select

if select() returns timeout,
a check for shutdown is made. This is set in a PO by someone else -
the main program

Another task waits in select/accept for clients to
call it for sending messages - on the same socket,
or to shutdown

A third task calls the second task with keepAlive messages,
periodically, with checks for shutdown mode

A client to the package (usually main) may call shutdown,
which set shutdown-mode in the PO, and closes the global socket.

Closing the socket causes receiving task to unblock, read,
and realize shutdown-mode thus exit.



-- 
--
Björn