This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: "Threads on ecos" confirmation needed...
Hello again.
Of course, but you can't do that with stacks (well, you can if you use the
same stack size for each thread).
Even if you could you'd still need per-thread clean-up code.
Why this can't be done with stacks? The "exit" method is quite simple
and can be modified
not to use stack variables. Initial creation of stack-frame and saving
the return address can be
avoided, I think, using "__attribute__" (or similar) gcc directives. Or
thread->exit() may
be inline... And per-thread clean-up code is ok for me, only if it can
be done either by the
thread that is about to exit, or by the *exit() function.
IH> The stack could be freed/cleaned by the exiting thread before calling
IH> *exit() (I think) and
IH> the above solution would "free" the space for thread object.
You're calling the thread->exit() so the return address is placed on the
stack.
Of course. But I'm using MIPS, and it doesn't automatically place the
return address on the stack.
The call to exit() could be performed from "asm" macro, without saving
the return address.
Thread never returns from thread->exit(), so return address is not
needed any more.
However, this problem can also be solved by temporarily switching the
stack of the thread (with
some simple synchronization) to universal "pre-exit stack", which would
resolve this and the above
(cleaning stacks) issue as well. This would be, of course, platform
dependent, but still simple.
You can create a wrapper around the 'thread' object and modify "exit"
function.
Yes, that's the other possibility.
The "garbage collector" could be included inside the "idle" thread.
Well, this is nice one. Why "idle" should idle, when it can be useful? :-)
Regards,
Ivan.
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss