lion03 / thrust

Automatically exported from code.google.com/p/thrust
Apache License 2.0
0 stars 0 forks source link

Destructors must not throw exception #188

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Some execution paths in Thrust can throw exception in destructor. It is lead to 
call terminate() if we already processing some exception (for example see 
http://www.gotw.ca/gotw/047.htm). For example I have next call stack:

-----------------------------
device_vector::~device_vector
vector_base::~vector_base
contiguous_storage::~contiguous_storage
contiguous_storage::deallocate
...
thrust::detail::device::cuda::free
-----------------------------

and last function (free) throw exception which uncatched at all levels, 
including destructors.

Yes, I know that this error mean that I have broke CUDA device. But in any case 
- destructor must not throw.

Original issue reported on code.google.com by repa...@gmail.com on 3 Aug 2010 at 8:50

GoogleCodeExporter commented 8 years ago
It is seems that solution is near Issue 37 (boost/std system_error).

Original comment by repa...@gmail.com on 3 Aug 2010 at 8:54

GoogleCodeExporter commented 8 years ago
Here is a dissenting opinion:

http://www.kolpackov.net/projects/c++/eh/dtor-1.xhtml

I don't believe there exists any reasonable alternative at this time: if we 
didn't allow ~device_vector to throw, how would we propagate the CUDA error to 
the user?  CUDA errors are unrecoverable -- why does it make sense to silently 
continue program execution?

Original comment by jaredhoberock on 3 Aug 2010 at 6:13

GoogleCodeExporter commented 8 years ago
The dissenting opinion is very bad. The examples is very strange, moreover some 
of them is incorrect. The key idea of this paper is: "Even though Abort might 
be an overkill in some cases, it is the most ethical solution from all that 
were proposed."
But why is it "most ethical"? Because if program continue it can damage some 
data? And the solution from author of paper is to terminate program. 
He lack the other possibility of damage data. Not by action, but by inaction.

For example if MS Word with document (which not saved for last 4-8 hours) is 
terminated when You start spell check because it can't close some file with 
dictionary in right way? Will You be the disappointed? I think You will be 
furious.

In MOST cases it is not to know that destruction is unsuccessfully. For example 
- if i destroy the mutex and OS call return error. It mean (among other) that 
this object can't be used any more. But I destroy mutex, so I won't use it in 
any case! So the fail in destructor is not important for me. The free of memory 
is same case. I don't really need to know about errors at "free". Because I 
won't use this memory any more.

If I broke the CUDA subsystem then I got error at the future. For example at 
next constructor. Constructor can (and must use) exceptions for inform about 
errors. But it is MORE preferable than terminating my program without any 
possibility to save _user_data_.

The solution, as I say in comment 1, probably is to use boost/std::system_error 
(Issue 37). The free function must support unthrowing syntax, and destructor 
must use this syntax.

Original comment by repa...@gmail.com on 6 Aug 2010 at 7:36

GoogleCodeExporter commented 8 years ago

Original comment by wnbell on 6 Feb 2011 at 6:48

GoogleCodeExporter commented 8 years ago
Forwarded to https://github.com/thrust/thrust/issues/65

Original comment by jaredhoberock on 7 May 2012 at 9:10