From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-06-08 08:49:35
"Peter Dimov" <pdimov_at_[hidden]> wrote in message
> Johan Nilsson wrote:
> > "Michael Glassford" <glassfordm_at_[hidden]> wrote in message
> > news:c9qn4v$s45$1_at_sea.gmane.org...
> >> "Johan Nilsson" <johan.nilsson_at_[hidden]> wrote in message
> >> news:c9pn3h$q4a$1_at_sea.gmane.org...
> >>> "Michael Glassford" <glassfordm_at_[hidden]> wrote in message
> >>> news:c9nemm$gt8$1_at_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)?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk