|
Boost : |
From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-06-07 02:18:21
"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 ...
The 63-threads limit shouldn't be a problem in well-designed applications,
it actually should be more than sufficient. If going for a watchdog-thread
based solution, I'm not so sure it's worth the effort to support more than
so due to the added complexity (at least that's my initial impression).
Regards,
Johan
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk