Re: [ECOS] cyg_thread_kill and info threads

[Jesper Skov <jskov at redhat dot com>]

>>>>> "Andrew" == Andrew Lunn <andrew.lunn@ascom.ch> writes:

>> But if you blast the thread object itself to zero, or arbitrarily
>> re-use the memory, that would break the pointers, and a subsequent
>> new-thread operation would go wrong as it scans the list as part of
>> adding that new thread - it is tolerant to re-initializing an
>> active thread object, ie. adding it to the list a 2nd time.

Andrew> So my malloc()ing/free()ing the thread object was a bad idea
Andrew> and only worked till now because of luck and not that high a
Andrew> rate of thread turn over.

Andrew> Please could you have the documentation updated to expain all
Andrew> this. Im sure im not the only one to make this mistake and a
Andrew> little bit of documentation will stop a lot of head
Andrew> scratching.


Jonathan has provided the below for the next version of the docs.

Jesper


cyg_bool_t cyg_thread_delete( cyg_handle_t <i>thread</i> )

Kills <i>thread</i> and deletes it from the scheduler. If necessary, it
will kill <i>thread</i> first using cyg_thread_kill(<i>thread</i>). If
<i>thread</i> does not terminate in response to the kill message, this
function returns false, indicating failure.

This function differs from cyg_thread_kill() (or calling cyg_thread_exit()
for the current thread) by deregistering the thread from the scheduler. As
a result, the thread handle, thread stack and space passed for the thread
housekeeping information can then be reused. This is not the case if just
cyg_thread_kill() or cyg_thread_exit() is invoked for the thread.

NOTE cyg_thread_delete() only deregisters the thread from the scheduler, it
does not free up any resources that had been allocated by the thread such
as dynamic memory, nor does it unlock any synchronization objects owned by
the thread. This is the responsibility of the programmer.