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