Gilles Chanteperdrix wrote: > On Tue, May 13, 2008 at 10:26 AM, Jan Kiszka <[EMAIL PROTECTED]> wrote: >> @@ -1236,6 +1236,9 @@ void xnpod_delete_thread(xnthread_t *thr >> xnthread_cleanup_tcb(thread); >> >> xnarch_finalize_no_switch(xnthread_archtcb(thread)); >> + >> + if (xnthread_test_state(sched->runthread, XNROOT)) >> + xnfreesync(); >> } > > No, this does not look good. The point of deferring TCB freeing is > that the TCB will be accessed shortly after it is freed.
By whom in this case? The thread was not active anymore. IIRC, the use-after-release issue was related to self-deletions. > > IMHO, the right solution is to add a call to xnpod_schedule or even > directly xnfreesyng in the right place (in skins code, after all > threads have been freed) Well, as I said, we should rather move all these syncs out of critical sections. So better avoid xnpod_schedule. I need to think about this a bit more, I'm afraid. It is safe to delete the TCB once the terminating thread is scheduled away and its successor of about to leave (or left) xnpod_schedule, right? Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core