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]

Re: thread suspend/kill/delete


Robin Farine <acnrf@dial.eunet.ch> writes:

> 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.

Indeed. This is why applications have to be careful in using them. In
general threads should not be unilaterally killed, but should be
allowed to call cyg_thread_exit() themselves.

> 
> Different ways of solving this problem follows.
> 
> 1. Never use those primitives (a bit restrictive and why should the API define
>    them then).

Yes we could delete them and say that the only facility for halting
threads is cyg_thread_exit(). But that would be unnecessarily
restrictive.

> 
> 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.

This all depends on the application and how it is written. Most
applications can easily arrange for threads to be given an exit
indication. This really does not need a general purpose mechanism to
support it.


> 
> 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<>).

This is far too complicated. eCos is meant to be a simple system. If
you want something like this, then use POSIX.

> 
> 4. Applications make use of higher level APIs only, such as pthreads, but what's
>    the point of the whole eCos C API then.

Because the C API predates the POSIX support, and POSIX comes with a
lot of extra baggage that many applications will not want. The C API
is meant to be a thin veneer over the basic kernel primitives, and not
a complete programming environment.


-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK


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