M. Koehrer wrote: >> On Wed, 2006-11-22 at 14:14 +0100, Jan Kiszka wrote: >> >> [...] >> >> >> Well, it actually does in intra-kernel calls, where rt_task_self() >> returns the container object of the base nucleus thread present in the >> RT_TASK struct the user passed us, even if nobody should rely on this >> fact. I would try to clear any confusion like this: >> "The address returned points at a descriptor identifying the calling >> task, which might be different from the descriptor address passed to >> rt_task_create()." >> >>> Jan >>> >>> >>> PS: Who's supposed to free the descriptor allocated by rt_task_self? >>> Would some check for pthread_getspecific(__native_tskey) + free() on >>> task self-destruction make sense? Will not catch all cases, I know. >>> >> 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. > What about the idea that it is possible to retrieve the cookie that is used > with > rt_task_start() ? > E.g. this could be provided with rt_task_inquire()?
Will require a syscall that is orders of magnitude slower than any __thread variable. Nevertheless, I don't see a reason why we shouldn't provide such trivial service via rt_task_inquire. Could serve as a kind of fallback then for weird architectures with lacking native TLS support. And might be useful for other purposes as well. > The rt_task_info struct has to be expanded for that. > > The main use case for this is that some user specific, task related data > has to be stored. One pointer should be sufficient. > I think, an approach that uses the Xenomai API for that is better than > to rely on TLS or NPTL as it is unclear if related actions lead to an > unwanted syscall. The only reason to not rely on TLS support provided by recent NPTL is that there is no NPTL. I don't share your concerns for the reasons I wrote in the reply to Daniel. > > One (very ugly) approach could be to code an address into the name of the > task. > This name could be retrieved via rt_task_inquire()... > > Mathias > Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
