"Peter Dimov" <pdimov@mmltd.net> wrote in message news:01fc01c44d59$76b94d20$0600a8c0@pdimov...
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...
[...]
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.
Ok, I have zip experience in using pthreads, only Win32 threads and the boost.thread library. If that's a definite requirement for the implementation it'll be virtually impossible to implement under Win32 (assuming static linkage to boost.thread) - without limiting users to use tss from "boost threads" only, IMHO.
They are even allowed to use thread-specific storage themselves.
Do you mean that the "destructors" can allocate/use tss under execution, or? What is the definition of "destructors" under pthreads, anyway (I assume it's not the same as a C++ destructor)? // Johan