This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

thread suspend/kill/delete


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]