run-time Task Control Block allocation

[stevech]

For an application that needs to create multiple instances of the same code for a task or other run-time decisions, and the number of tasks isn't known at compile-time, how would this be done in ZBasic? There is nothing similar to malloc() and free() that I've found, i.e., malloc() a TCB for the task's use.

I tried but didn't see a way to coerce makestring() into malloc, for a byte array, by calling a string function that uses makestring().

Maybe there's some way to have a sub DIM b() as Byte in local storage and pass that as the TCB, and have that sub delay returning until the task exits. Seems awkward - someone may know a better way in ZBasic!

[mikep]

My first response is what are you trying to do exactly? Tasks consume resources and need to be managed (see application notes AN-209 and AN-210) and so should not be take lightly.

To answer your question, the memory address for the task stack is determined at compile time and not runtime. Part of the reason for this is so that all of the global memory is known about prior to runtime and the remaining memory is allocated to the "main" task. Therefore you cannot do what you are asking.

It is actually a good thing that ZBasic handles most of the memory management for you. Malloc and Free are the #1 causes of bugs in C code. The only dynamically allocated resource (except for the main stack) are strings which are stored in a different part of the memory map - the heap if you like.

[stevech]

As to the goal:

I'm merely comparing the multitasking capabilities to other operating systems I've used in the past to solve various needs. In many or even most, you don't know at design-time how many instances of what tasks are needed because tasks come and go as real time I/O events happen. And there may be 2 or more active instances of the same task-code on occasion.

Just a general question.

[dkinzer]

[spamiam]

[dkinzer]

Yes, it is true that you can have multiple, concurrent invocations of a specific task but each must have its own task stack.

What 'stevech' was hoping for was to have the task stacks automatically allocated for each task invocation, obviating the need to declare them in advance. This would be nice, of course, but I think it is impractical with the resource limitations of the mega32.

[stevech]

No need for automatic TCB creation - just a means to get an array of bytes at run-time and use that as the TCB. Many of these tasks need only 50 or so bytes for each instance - which isn't always known at design-tme.

I tried
dim s1 as string, s2 as string
dim t() as bytearray ' does this work?

s1=""
s2=makestring(s1, 50) ' gimme some heap

now if I can "cast" that to an array of bytes I have a TCB, eh?

t = cbytearray(s2) ' ????

calltask ("IamPolyMorphic", memaddress(t))
or
calltask ("IamPolyMorphic", straddress(s2)+4) ' ???

and again as needed.

Or I am totally full of it.
-------------

By the way: Why does calltask use the string name of the sub rather than it's symbol name, since this is compile-time code generation?

[dkinzer]

[stevech]

I have a large VB6 application that runs 24/7 to present a variety of home theater and web surfing options in menus on the family TV. There's a date/time based scheduler in VB6 inside that App - that I wrote. It uses VB6's CallByName capability to implement the scheduler. When I first saw the ZBasic call task with a string argument, I thought about that! The task name is computed at run-time and put in a string.

So both task-by-name and task-by-compiler-symbol are useful.

(given the run time creation of a TCB for some situations)

[dkinzer]