On 08/10/2012 04:02 AM, Mathieu Desnoyers wrote: > Looking at the result of a quick google search: > > http://curl.haxx.se/mail/lib-2006-09/0224.html > http://www.slamb.org/projects/sigsafe/api/patternref.html > > "Additionally, it makes the same assumption as all other methods for > handling thread-directed signals (with the exception of kevent(2) > handling), that pthread_getspecific(2) is async signal-safe. This is not > guaranteed by SUSv3." > > and > > https://groups.google.com/forum/?fromgroups#!topic/comp.os.linux.development/nZfmndKbzJw[1-25] > > it looks like using pthread_getspecific from a signal handler is not > always safe, mainly due to possible use of sigaltstack. So disabling > signals works for the "pthread_key_create" part, but we still have an > issue with pthread_getspecific. > > Ideas are welcome on how to best deal with this issue.
What's the problem with disabling signals + pthread_getspecific()? Waht's the problem with disabling signals + __tls_access_ ## name()? _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
