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: "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>
Newsgroups: comp.lang.ada
Subject: Re: Launching background job from Ada.Real_Time.Timing_Events
Date: Tue, 24 May 2016 16:52:32 -0700
Organization: Also freenews.netfront.net; news.tornevall.net;
 news.eternal-september.org
Message-ID: <ni2p96$45d$1@dont-email.me>
References: <ni1nsh$46j$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 24 May 2016 23:48:56 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="48b46be33beed75863f69afa437f956b";
	logging-data="4269"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18GgItP0r8vsJpxs8fe7nn7exrhpuVd6i4="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.8.0
In-Reply-To: <ni1nsh$46j$1@dont-email.me>
Cancel-Lock: sha1:dd+KP30BPCF6pr/O8Ah+jvf5gyY=
Xref: news.eternal-september.org comp.lang.ada:30477
Date: 2016-05-24T16:52:32-07:00
List-Id: <comp.lang.ada>

On 05/24/2016 07:22 AM, Alejandro R. Mosteo wrote:
>
> My idea was to queue the job when the event is triggered, and to have a worker
> thread waiting for jobs in the queue. However, I've just realized that the event
> handler is itself a protected action, so I can't call another potentially
> blocking enqueue from there.

I can see how this would work, with the queue in the same PO as the handler as 
Lorenzen suggested, but it seems messy to me. You need to store the 
Timing_Events somewhere until they're handled, and since they're limited that 
will require using access types. That in turn requires doing memory management, 
and that will probably need another task to periodically look at all the events 
and free those that have been handled. This has lots of opportunities for error.

A simpler approach would be to package up a Time and your job info in a record 
you can put on a priority queue in Time order, and have the worker task do a 
delay until the Time. The only problem with this is that you need to have enough 
tasks to ensure all jobs are started at the appropriate time, or a willingness 
to create a new task if an event is queued when there are no workers available. 
I have used the latter approach and it works fine if dynamically created tasks 
are acceptable.

-- 
Jeff Carter
"This scene's supposed to be in a saloon, but
the censor cut it out. It'll play just as well
this way." [in a soda fountain]
Never Give a Sucker an Even Break
113