Re: [ECOS] thread suspend/kill/delete

[Robin Farine <acnrf at dial dot eunet dot ch>]

nicolas lacorne <Nicolas.Lacorne@sun.com> writes:

[...]

> >
> > However, after some more thoughts about the restrictive character of removing
> > kill() and delete(), I cannot find any example of an application that safely
> > kills a thread from another thread where the killed thread cannot do it
> > itself. Those primitives allow programmers to (innocently) choose the easy and
> > wrong way rather than they offer them useful functionalities; a somewhat similar
> > but extreme case would be a thunder-mutex, fast as hell, but you can only
> > acquire or release it when you're sure that no other thread will access it
> > during the whole operation ;-)
> >
> 
> I think that one uses of cyg_thread_kill() is when  you desallocate stack from one
> threads with another.
> Because it would be uncorrect to desallocate  memory for a thread stack inside his
> own code.
>  Example:
>   Threads A : before ending he mail killer thread his handler and his stack base then
> set killer thread priority to maximum one.
>    Killer thread : kill thread A and desallocate stack A then came back to minimal
> priority.

But in this example, since thread A will terminate, he will finally call the
Cyg_Thread::exit() function and thus enter the EXITED state. Your killer thread
could be called "reaper thread", he would scan the threads list for EXITED
threads in order to reclaim any memory dynamically allocated at the thread's
creation. The POSIX threads layer does just that, no need for the kill()
functionality.

[...]

Robin