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: "Alejandro R. Mosteo" <alejandro@mosteo.com>
Newsgroups: comp.lang.ada
Subject: Re: Launching background job from Ada.Real_Time.Timing_Events
Date: Thu, 2 Jun 2016 23:22:14 +0200
Organization: A noiseless patient Spider
Message-ID: <niq81j$r7g$1@dont-email.me>
References: <ni1nsh$46j$1@dont-email.me> <ni2p96$45d$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 2 Jun 2016 21:21:55 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="857d06a4b85f2c044993090b381d5d42";
	logging-data="27888"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19MnR4QVD5kS5PRwuZBjcGy"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
In-Reply-To: <ni2p96$45d$1@dont-email.me>
Cancel-Lock: sha1:Yw/GxIBtuqjwFh6q7rXrENVWi74=
Xref: news.eternal-september.org comp.lang.ada:30555
Date: 2016-06-02T23:22:14+02:00
List-Id: <comp.lang.ada>

On 25/05/16 01:52, Jeffrey R. Carter wrote:
> 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.

I'm in no need for strict real time requirements so I can do with this 
softer approach. Thanks for the suggestion.