Starting a Task and Immediately Returning

Starting a Task and Immediately Returning

[Graham Stark]

Apologies if this is obvious, but I can't figure it out.

I'm doing some work with the Ada Web Server. I want a user to be able
to submit a job via a web page that might run for 10-20 minutes, and
have the server duly start it but respond immediately with a reply
like "your job has started" (as a web page).

So, something like:

function Web_Callback (request : in AWS.Status.Data) return
AWS.Response.Data
begin
  Start_Long_Job( ... );
  return "your job has just started";
end Web_Callback;

Can I do this using Ada's tasking facilities? So far as I understand
them, all the Tasking examples I've looked at would have the return
executed only after Start_Long_Job has completed. Is that right? But,
obviously, you can't wait 10 minutes to reply to a web request.

Or is there some other way of doing this?

Graham

Re: Starting a Task and Immediately Returning

[Maciej Sobczak]

On 14 Lis, 14:26, Graham Stark <graham.st...@virtual-worlds.biz>
wrote:

> Can I do this using Ada's tasking facilities?

Yes.

> So far as I understand
> them, all the Tasking examples I've looked at would have the return
> executed only after Start_Long_Job has completed. Is that right?

If the task is created locally then yes, this is what will happen -
the enclosing scope (Web_Callback) will wait for the termination of
its locally created task.

> But,
> obviously, you can't wait 10 minutes to reply to a web request.

Then you need a task that will exist independently on Web_Callback.
Make such a task (or even a whole bunch of them if that makes sense
for this particular server) at the library level, which will give them
independence on any scope. Add some facility for communicating to this
task the description of what needs to be done (the "job") - for this
you can use rendezvous or (better) job queue(s).

In such a setup, your Web_Callback function can post the job to the
queue without waiting for it being actually done, whereas the worker
task can pick it from the queue and execute it in "background", while
the final user enjoys the "your request has been accepted" page.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: Starting a Task and Immediately Returning

[Jean-Pierre Rosen]

Maciej Sobczak a �crit :
> On 14 Lis, 14:26, Graham Stark <graham.st...@virtual-worlds.biz>

>> But,
>> obviously, you can't wait 10 minutes to reply to a web request.
> 
> Then you need a task that will exist independently on Web_Callback.
> Make such a task (or even a whole bunch of them if that makes sense
> for this particular server) at the library level, which will give them
> independence on any scope. Add some facility for communicating to this
> task the description of what needs to be done (the "job") - for this
> you can use rendezvous or (better) job queue(s).
Or more simply, create the task with an allocator (new). The tricky 
thing will be to deallocate the tasks' space after it is terminated. Web 
server are generally expected to run 24/7, so no memory leak allowed...
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Starting a Task and Immediately Returning

[Samuel Tardieu]

>>>>> "Jean-Pierre" == Jean-Pierre Rosen <rosen@adalog.fr> writes:

Jean-Pierre> Or more simply, create the task with an allocator
Jean-Pierre> (new). The tricky thing will be to deallocate the tasks'
Jean-Pierre> space after it is terminated. Web server are generally
Jean-Pierre> expected to run 24/7, so no memory leak allowed...

...and deallocating all the space used by a task in Ada is often a
no-no when you use a long-lived task type, as you need to be able
to query 'Terminated on a former task object at any time after the
task has terminated, so some information has to remain (the task
status) or some arbitrary limit has to be set (use a unique counter
when creating a task and a bitmap to indicate the termination
status, forbidding you to reuse a task "number" since the status
has to live forever). Both are bad in a system which is expected
to run forever.

A solution would be for a compiler to make task types a reference
counted type so that the runtime knows when 'Terminated can be
called or not. I haven't checked if this is what GNAT does.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

Re: Starting a Task and Immediately Returning

[sjw]

On Nov 15, 12:04 pm, Samuel Tardieu <s...@rfc1149.net> wrote:

> ...and deallocating all the space used by a task in Ada is often a
> no-no when you use a long-lived task type, as you need to be able
> to query 'Terminated on a former task object at any time after the
> task has terminated, so some information has to remain (the task
> status) or some arbitrary limit has to be set (use a unique counter
> when creating a task and a bitmap to indicate the termination
> status, forbidding you to reuse a task "number" since the status
> has to live forever). Both are bad in a system which is expected
> to run forever.
>
> A solution would be for a compiler to make task types a reference
> counted type so that the runtime knows when 'Terminated can be
> called or not. I haven't checked if this is what GNAT does.

The way GNAT works, I believe -- and possibly not on all OSs -- is
that attempts to deallocate a task that isn't terminated are silently
ignored. On the other hand, it seems that deallocating a task which is
terminated does the right thing.

You clearly need to be able to ask a declared task whether it's
terminated at any time, but I don't see why that would apply to
allocated tasks? 'Terminated on a dangling pointer (deallocated
elsewhere) would be no worse than any other reference through such a
pointer.