Johan Nilsson wrote:
"Michael Glassford" <glassfordm@hotmail.com> wrote in message news:c9qn4v$s45$1@sea.gmane.org...
"Johan Nilsson" <johan.nilsson@esrange.ssc.se> wrote in message news:c9pn3h$q4a$1@sea.gmane.org...
"Michael Glassford" <glassfordm@hotmail.com> wrote in message news:c9nemm$gt8$1@sea.gmane.org...
[snip]
Implementing the solution another poster mentioned (have a
wait either on thread termination or an event signalling a new
background thread thread
request TSS data) would be better.
Except that Malcolm, who mentioned that approach, abandoned it as unworkable--or was that only the optimization? But without the optimization you'd have to create a "watchdog" thread for each thread being watched, which doesn't sound like a good idea, either.
I agree that it's worth looking into, though, to see if the problems he had can be dealt with.
I meant including the optimization; i.e. (definitely) _not_ creating one "watchdog" thread for each "real" thread. Problem being, as he mentioned, that WFMO only takes so many events; making it necessary to create one watchdog thread for every 63 user-threads. I don't see any implementation problems with this approach as long as it would only be used inside executable modules (i.e. static linkage), but as I haven't actually tried to implement it ...
POSIX-conformant thread-specific storage destructors run in the context of the thread that is about to exit, AFAIK. They are even allowed to use thread-specific storage themselves.