|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-06-08 08:06:46
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...
>
> [snip]
>
>>>
>>> Implementing the solution another poster mentioned (have a
>> background thread
>>> wait either on thread termination or an event signalling a new
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk