Re: Formal review: New Boost.Test Library

From: bill_kempf (williamkempf_at_[hidden])
Date: 2001-12-11 17:45:58

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 04:53 PM 12/11/2001, rogeeff wrote:
> 
>  >Timeout is implementing only for UNIX platforms using alarm and
>  >SIGALRM hadnler. It's pretty portable solution (on UNIX 
platforms).
> 
> I have two different implementations for Windows timeout code 
contributed a 
> while ago by two different people.  The Win32 implementations are a 
lot 
> less straightforward (they start additional threads) than the UNIX 
> implementation, so I didn't add them during the initial stages.
> 
> The real problem is that I have no serious knowledge of the Win32 
specific 
> API's, and was afraid to add code that I didn't entirely understand.
> 
> While I understand Bill Kempf's worry, it seems to me the solution 
is to 
> find some Win32 experienced developer to add that platform - 
perhaps 
> Glennadiy qualifies, or the folks who contributed Win32 timeout 
> implementations.  It is a nice feature (invented by Ulli) and we 
should 
> support it if possible, IMO.

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.

Timeouts are only useful to detect and *recover from* infinite 
loops/deadlock.  I think an infinite loop is a critical error and no 
attempts to recover should be made... even in a unit test framework.  
So if the timeout concept were changed so that the test were run in a 
new thread and if the thread doesn't complete before the timeout 
expires the program simply aborted (with appropriate logs) then I'd 
consider the idea to be more portable and worthy of inclusion.  But 
attempts to recover and continue won't be portable and aren't worth 
implementing, IMHO.

Bill Kempf