On Wed, 2006-11-22 at 17:34 +0100, Gilles Chanteperdrix wrote: > Philippe Gerum wrote: > > On Wed, 2006-11-22 at 15:03 +0100, Gilles Chanteperdrix wrote: > > > >>Philippe Gerum wrote: > >> > >>>On Wed, 2006-11-22 at 14:14 +0100, Jan Kiszka wrote: > >>>We could add that, and the same stuff upon return from the task body > >>>inside the trampoline call, but the only way to solve this with no leak > >>>would be to call the nucleus at each invocation, and not use any cached > >>>descriptor here. Since TLS requires to be operated by the owning task, > >>>there is no point in trying to have a deleted task clean those up > >>>thoroughly. > >>> > >> > >>When creating a TLS key, you can specify a cleanup function that get > >>called when a thread exits (or is canceled). > >> > > > > > > Actually, there are spots where the nucleus forces do_exit() over the > > caller, and specifically, when we zap a shadow from the Xenomai context, > > then perform a tail scheduling for this zombie over the incoming Linux > > context. In such situation, the user-space would not even be informed of > > what's been going on, so the cleanup routine would be useless. > > IIRC, rt_task_delete calls pthread_cancel,
Not in the case of self deletion, it seems. > so tasks deleted with > rt_task_delete should be able to run the cleanups before exiting. The > fact that in some cases (namely, in the case of unclean exit) some > chunks of memory are not deallocated seems acceptable. > Problem is: destroying a thread from primary mode _is_ clean too, and likely often used. -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
