i'm going crazy with task

i'm going crazy with task

[mferracini]

i'm working on a user defined task scheduler.

my problem is:
if a task type is defined in a package how i can export a pointer to
this task?
the main problem is that the task have a "generic" part so an user can
write different body for thid task.

it look like this

task type dummy is
entry dosomething;
....
task body dummy is
...
loop
accept dosomething
user_defined_work;  <--generic part.
end loop;
....

the problem is that the task type is visible only inside the pakage.
my idea is to crate a scheduler task with an array of pointer of dummy
task
but

if i put the scheduler in the package, evry time that i make a new
dummy task a new scheduler start.

if i put the scheduler outside the pakage i can't define the the arry
of task.

using some trick (like win32 package) is possible have a pointer to the
entry of a task?

thanks

Re: i'm going crazy with task

[mferracini]

mferracini wrote:

> using some trick (like win32 package) is possible have a pointer to
the
> entry of a task?
> 
> thanks

or a signle istance of the scheduler :-/

Re: i'm going crazy with task

[Alex R. Mosteo]

mferracini wrote:
> mferracini wrote:
> 
> 
>>using some trick (like win32 package) is possible have a pointer to
> 
> the
> 
>>entry of a task?
>>
>>thanks
> 
> 
> or a signle istance of the scheduler :-/

If I have understood you right, I don't think you could get away with 
that in Ada 95 using generics.

You could, instead, use an OO approach and have something like:

type Runnable is abstract limited null record;

procedure Run (This : in out Runnable) is abstract;

Users would then inherit from the runnable object, providing 
implementation for the Run procedure.

Then your task specification could be:

task type dummy (Code : access Runnable'Class) is
    entry Run_It;
end;

and in the body you simply call the dispatching procedure

Run (Code.all);

I hope this make sense to your problem.

Re: i'm going crazy with task

[Adrien Plisson]

Dennis Lee Bieber wrote:
> 	If I understand this description of the situation, I fear you
> have bigger problems ahead.  Ada "task"s are ALREADY handled by the
> run-time task scheduler. I don't know how you'd implement a scheduler on
> top of (or in place of) that scheduler...

he may be talking about a task scheduler ala Windows, that is a piece of 
software whose goal is to launch some user specified actions at the occurence 
of some event: time, boot, ...

a unix equivalent is crond.

-- 
rien

Re: i'm going crazy with task

[Adrien Plisson]

Dennis Lee Bieber wrote:
> 	Such should only require some data structure for the event
> timing, and the externally created process to be started (path to a
> script file, perhaps). But the original question seemed to be assuming
> diverse internally coded processes... Okay, I suppose timed one-shots
> could still be applied to internal code modules -- and those could be
> (very rough description here) handled as a sort of call-back from the
> timer to plain procedures.

i was only making suppositions on what the OP was trying to do, i don't speak 
on behalf of him. so, until he posts some more informations, we can't assume 
anything on what he is trying to do. i only raised the point about the 
scheduler because the term is confusing.

you are right pointing out that a "task scheduler" should not need that much 
tasks, but you forgot a case which forces the use of tasks. consider that 
actions of the scheduler are internal procedures. if you implement it with 
callbacks, the scheduler will block until the actions terminates. if actions 
are lengthy, you have a problem. the solution is from the scheduler to create a 
new task which will call the procedure.

anyway, even when doing this there is no need for a big array of tasks...

-- 
rien

Re: i'm going crazy with task

[mferracini]

Adrien Plisson wrote:

> i was only making suppositions on what the OP was trying to do, i
don't speak
> on behalf of him. so, until he posts some more informations, we can't
assume
> anything on what he is trying to do. i only raised the point about
the
> scheduler because the term is confusing.

i'm sorry, my english is not good :)

i need to write a "simulator" of a task scheduler.
my idea is:
cerate a new task with an entry called "run" that esecute user-defined
code in this way:
-----------------------------------------------------
with Task_Maneger;
with User_App;

package Test_1 is new Task_Menager.Det_Task
(Task_Job => User_App.Task_Job);
-----------------------------------------------------

when i create the task "Test_1" i need to pass his poiter to the
scheduler,
that call "Task_job.run" .

greatings from Italy
Michele.

Re: i'm going crazy with task

[Adrien Plisson]

Dennis Lee Bieber wrote:
> 	A fancier version would create a task for each entry; the core
> of each task is just:
> 
> delay until start_time
> user_app_main()

this is a bit overkill: if you have many jobs to run, you will start by 
creating that many tasks which will stay idling in the background until 
start_time.

i know that a task does not (or should not) consume processing resources while 
idling, but they still uses memory resources and they certainly uses system 
resources (system objects as handles or such) which may be limited.

a better approach would combine the priority list/queue of the first case with 
the task creation of the second:

while queue.notEmpty loop
     pull job from queue
     delay until start_time
     create a task and pass it the user_app_main function
end loop

and the core of the task will just have to call the given function at startup 
and die when it has terminated. this way the tasks exists only when needed, 
thus limiting resource consumption.

> 	Simulating what /I/ think of when I hear "task scheduler" is
> going to be much more difficult.

it's interresting to see that our interpretation depends on the level we see 
the problem. you see the task scheduler at the very low level of scheduling 
processes for pseudo-concurrent execution on a single processor. i see the task 
scheduler at the high level of deferred process execution.

-- 
rien