Re: [Xenomai-help] What returns rt_task_self in

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2386 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]