Re: request for feature
- Posted by mattlewis (admin) Sep 25, 2012
- 1277 views
Can tasks.e use some fast database methods to page out unscheduled tasks to the harddrive? The goal to free up memory and task pointers.
This strikes me as fairly difficult for the interpreter. We'd need to serialize all of the private data for the entire stack of the task as well as be able to jump back to the appropriate point where execution left off.
Where I think this would be really tricky is with the translator. I'm not even sure it's possible without doing lots of nasty stack manipulation (which was what broke the old task implementation when we started looking like a stack smashing piece of malware to the OS).
I wish to cycle thru lists of functions (procedures) to do similar, i guess, to how a cron job scheduler would work, and each task does things in the global application, then when it's done enough, and enough times, it can be paged out until needed again. The problem is the task system can run out of memory and pointers, if i leave this running, with intent for it to keep on for a year, it could crash in 11 months simply by filling all memory with task overhead, and i will have wasted all that time.
Alternatively, you might add a layer between std/task.e and the parts of your code that use them. This way, your task overseeing code refers to the tasks by whatever sort of ID system you like. Your tasks would have to actually end instead of just suspend, at which point all of the task memory would get recycled.
I don't understand your program well enough to say much more about the logic involved in deciding when to suspend / yield vs complete the task. But your task abstraction layer could keep track of the status of a given task and re-start them when required.
This ability might also please those who wanted dynamic includes: just load the code up as a procedure with it's local variables intact, and schedule it.
This hits the same issues as above.
Another good part of this: altho the task reloaded would not be available as ordinary Eu code to be called as a procedure, it would be great to be able to call it as two different tasks. So if have an app, and in my app i have procedure x(), and i call it as a task, then i save it thru the task_unload(), i can later task_load() it twice if i like. This means, of course, the benefit of recycling the task ID gets a new ID each time a task is _loaded.
I think you could probably accomplish a similar thing through the proposed abstraction layer above, assuming you allowed some sort of saved state that you could retrieve. I assume that one of the task routine's parameters would be whatever ID you are using in the abstraction layer. So you save off the info when you do the unload (in this case, really just returning from it). You could clone that info if you plan to have multiple tasks going later (assuming that the data could change while one active task is running) or whatever.
Matt
