In order to do resource recycling we need a table structure. In the search of
one, we concluded that a task list will make things easier when we start adding
COPY and NEW space handling.
This commit is for utcb recycling. Now, it does not support thread trees more
than one level depth. Thus, to be able to test it, we preferred l4thread_destroy
instead of l4thread_exit.
UTCB support has beed added. It has the same drawback as in the stack support:
the area in question has to be already mapped-in.
There are also some minor fixes for the stack support and the utcb common helper
routines.
The difference between this thread library and the existing ones like pthreads
is the necessity of informing the library about the address range of the stack
and the l4 specific utcb. Utcb has not been supported yet. As for stack, there
is also a drawback: library does not support mapping. In other words, the stack
area in question has to be already mapped-in. Thus, for now we only support
threads sharing their address spaces: TC_SHARE_SPACE. In this respect, it is
very similar to pthreads.
This is one of the steps we need in the process of providing a similar interface
for thread creation which can be found in the mainstream operating systems like
Linux.
Examples container type is designed to keep applications using codezero
userspace libraries, which is aiming to help newcomers who would like to
develop programs on top of the l4 microkernel.
Now bare bone application is one of the examples. In the near future, lots of
new programs will be introduced to show the various aspects of codezero
eco-system.
We still have to have the pager structs because they possess intermediate
data during boot up such as for transferring of capability lists to
boot stack one-by-one, and then to newly generated ktcbs.
Previously all pending events were handled on return of exceptions
in process context. This was causing threads that run in userspace
and take no exceptions not handle their pending events indefinitely.
Now scheduler handles them in irq context as well.
Multi-threaded apps can now wait on children to destroy.
WAIT_ON is useful when a child exists with an exit code and the pager
of the child does not want to take the hassle of destorying it via an
ipc. It provides an alternative method of synchronous thread destruction,
where the child destroys itself directly rather than the parent issuing
a destroy on it explicitly.
Pagers kill all children but suspend themselves.
Currently not straightforward for a pager to delete its own tcb and quit.
It should take all allocator locks without sleeping, remove itself from
scheduler queue and then delete itself and quit. This is not so easy now
as some allocation locks are mutexes. (Address space lock, ktcb/space
allocators etc.)
An easier approach would be to have a kernel thread or a superior thread
that would delete the pager
Reiterating again to simplify:
Working:
- Pager issues destroy, client also issues exit
they work in sync.
Missing
- Pager killing itself
- Pager killing all children while killing itself
- Pager waiting on children
Bora Sahin