This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
thread suspend/kill/delete
- To: ecos-discuss at sources dot redhat dot com
- Subject: [ECOS] thread suspend/kill/delete
- From: Robin Farine <acnrf at dial dot eunet dot ch>
- Date: 19 Sep 2001 11:14:35 +0200
Hi,
I feel a bit uncomfortable with the threads API functions cyg_thread_delete(),
cyg_thread_suspend() and cyg_thread_kill(). After looking at the sources, I
understand (please correct me if I missed something here) that a thread A may
suspend or kill another thread B without letting a chance to B to release any
resource (mutexes, dynamically alocated memory, ...), which could bring the
whole system into a very bad state.
Different ways of solving this problem follows.
1. Never use those primitives (a bit restrictive and why should the API define
them then).
2. Only use them on the current thread. This implies that the application
provides a mechanism for asking a thread to suspend, kill or delete itself
(through flags or mbox). But this also means that we will write our own
versions of this mechanism, again and again.
3. Introduce a pair of functions, cyg_thread_disable_suspend() and
cyg_thread_enable_suspend(), and a counter for nested calls to delay
actions. And perhaps the possibility to register a kill handler that gets
called from cyg_thread_enable_suspend() so that, for instance, a C++ program
could throw an exception to unwind its stack and thus release any resources
that it allocated in an exception-safe manner (e.g. by making use of
constructs such as STL's auto_ptr<>).
4. Applications make use of higher level APIs only, such as pthreads, but what's
the point of the whole eCos C API then.
Any comment on how to deal with this?
Robin