On Thu, 2007-05-10 at 16:53 +0200, Gilles Chanteperdrix wrote: > Philippe Gerum wrote: > > On Thu, 2007-05-10 at 11:33 +0200, Gilles Chanteperdrix wrote: > > > >>Philippe Gerum wrote: > >>>xnfreesafe was meant to prevent the caller from releasing some memory it > >>>could still rely on, e.g. stack space, by postponing the actual release > >>>until the idle thread is resumed. In your case, the problem is that it > >>>does not account for the primary/secondary mode of a shadow thread. > >> > >>I am not so sure. I mean, even if the thread was deleted from the > >>context of another thread, the two hooks would be invoked and we would > >>need the free operation to be deferred until after the execution of the > >>second hook. > >> > > > > > > The point is that deletion hooks are always called on behalf of the > > exiting thread in secondary mode, so if xnfreesafe properly identifies > > the caller as the current thread - regardless of its exec mode - then > > the deferral should always take place. But I agree on the fact that we > > should always end up running the deferred call in this context anyway, > > so we would be better off calling xnheap_schedule_free() directly. > > That is why, since xnfreesafe was only called in this precise context, I > redefined it to call xnheap_schedule_free directly. >
Well, ok. But we may need the xnfreesafe() interface in the future, the way it was designed initially, I mean. So let's call xnheap_schedule_free directly when needed. -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
