Re: [boost] Exception-safety (RE: [compute] review)

Subject: Re: [boost] Exception-safety (RE: [compute] review)
From: Kyle Lutz (kyle.r.lutz_at_[hidden])
Date: 2014-12-28 20:51:30

On Sun, Dec 28, 2014 at 5:03 PM, Gruenke,Matt <mgruenke_at_[hidden]> wrote:
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Kyle Lutz
> Sent: Sunday, December 28, 2014 14:42
> To: boost_at_[hidden] List
> Subject: Re: [boost] [compute] review
>
>> On Sun, Dec 28, 2014 at 1:54 AM, Gruenke,Matt wrote:
>
>>> I didn't notice any unit tests specifically intended to verify exception-safety.
>>> I'd want to know that had been thoroughly vetted, before I'd consider
>>> using Boost.Compute in production code.
>
>> There are already some tests which for the error/exception paths in Boost.Compute
>> (testing building invalid programs in "test_program.cpp" is the first that comes
>> to mind). I'll work on adding more. Please let me know if there are any specific
>> areas you'd like to see more heavily tested.
>
> The only exception-related tests I saw seemed to be a small number that simply checked whether exceptions were being thrown when expected.
>
> What I'm specifically concerned about is whether your containers and other wrappers are exception-safe.  I don't want memory or resource leaks (or worse!) in my programs, when I handle recoverable exceptions and continue executing.  I assume the bulk of your classes are simply RAII wrappers around the OpenCL C types, so they're probably fairly safe.  I guess I'm more concerned about containers and anything with nontrivial state.
>
> I don't know how much boost's unit test framework can help with this.  Certainly, it can exercise a number of cases and report if there are any segfaults.  But to check for resource leaks probably means also running them with a tool like valgrind, and examining the output.  I'd enable file descriptor tracking, in hopes that it might detect some resource leaks down in vendor-specific code.  Obviously, your library can only be as good as the underlying implementation, but the hope is that at least Boost.Compute doesn't add any leaks or errors of its own.

I have attempted as best as possible to make the library exception
safe. I will work on improving the unit tests to explicitly check for
exception safety and proper recovery. I'd welcome anyone to look over
the code and, if possible, provide test-cases which show incorrect
behavior.

-kyle