Re: Formal review: New Boost.Test Library

From: p_michel_andre (michel.andre_at_[hidden])
Date: 2001-12-12 04:13:13

--- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> My fear is in the "if possible".  The thread solution can only work 
> if you kill the thread, which under Win32 means a call to 
> TerminateThread() which is an abomination that never should have 
> existed.  Some will argue that the evils of this API are not so 
> serious in this particular domain since the resource leaks will be 
> very shortly recovered when the application quits... but I don't 
> agree.  TerminateThread() is evil incarnate and any use of it is 
just 
> going to lead to some sever consequence eventually.
> 
> *IF* a solution for Win32 can be found that's safe I'd change my 
mind 
> here (though *nix and Win32 are hardly the full gamut of platforms 
> and I'd generally prefer having a truly portable solution or 
none).  
> With out the Win32 solution you've got a feature that's *nix 
> specific, which doesn't cover enough ground to be useful, IMHO.
> 

I was one of the guys proposing a solution to Beman for the Alarm 
feature in NT. My solution doesn't use Terminate thread. Below is a 
short description:

The alarm class creates an external thread to handle the timeout and 
if an timeout occurs the external thread suspends the original thread 
and perfoms a GetThreadContexts and sets the x86 Eip program counter 
to a function that raises an user defined software exception which 
then can be caught via NT:s exception mechanism (and rethrown as an 
C++ exception to be caught). The interface was something like:
try
{
   Alarm alarm(1000);  // timeout in msecs
   lenghty_call();     // call that takes more than 1000 msecs
}
catch(Alarm::Timeout&)
{
   std::cout << "Timeout occured!";
}

But that can of course be changed.

Actually I havent got the code. Maybe Beman still has it. Ive had a 
disk crash so i have to rewrite it or reload an backup.

/Michel