Jan Kiszka wrote: > Hi, > > looking into the "xeno_in_primary_mode" thing I wondered how to make the > thread state quickly retrievable. Going via pthread_getspecific as we do > for xeno_get_current appears logical - but not optimal. Though > getspecific is optimized for speed, it remains a function call, a few > sanity checks, and only finally a TLS variable access. That could be > achieved in a much lighter way by using a __thread variable. > > But can we assume that all target we support also support the __thread > storage class? TLS is surely mandatory now: I assume pthread_getspecific > would become non-RT safe without it, right? Is there anything we > can/must check for during configure to verify __thread support?
I really think that this optimization is not worth the trouble. Anyway, I have one question: is an implementation guaranteed to support more than one __thread variable? Because from ARM implementation I would say that ARM has only one __thread variable. -- Gilles. _______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core