Re: [boost] Synchronization (RE: [compute] review)

Subject: Re: [boost] Synchronization (RE: [compute] review)
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2014-12-30 05:01:28

On December 29, 2014 6:49:35 PM EST, Kyle Lutz <kyle.r.lutz_at_[hidden]> wrote:
>On Mon, Dec 29, 2014 at 2:58 PM, Thomas M <firespot71_at_[hidden]> wrote:
>
>>Note that because your API can
>> throw I consider exception effects to be of much greater concern than
>with
>> the (implicitly non-throwing) Khronos API; and just enqueuing a
>couple of
>> commands can make a proper, manual cleanup really easily non-trivial.
>
>I have tried as much as possible to ensure that the library
>exception-safe (I surely hope you aren't assuming that I intentionally
>made the library non-exception-safe). If you do find any bugs related
>to exception handling please do submit them with a reproducible
>test-case to the issue tracker [1] and I will get them fixed as soon
>as possible. Also, in case you were unaware, you can always disable
>all exceptions in Boost.Compute by defining BOOST_NO_EXCEPTIONS.

BOOST_NO_EXCEPTIONS invokes a global handler to note a failure. That means after every library call, the user must check a global value to determine if there was an error. Overloading with a Boost.System error_code localizes error checking. (Asio does this, for example.) I consider that a superior way to avoid exception overhead.

The question is whether exception overhead is a bottleneck in coding with this library's API. It is necessary to weigh the likelihood of errors against the costs of reporting and detecting them. Conditional logic to check for errors is not pipelining friendly, but throwing exceptions is terribly expensive.
-- 
Rob
(Sent from my portable computation engine)