Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On 29/12/2011 19:09, Jacob Carlborg wrote: snip excessive quote Could druntime hook up on the atexit function to run destructors and similar when the program exits? I'm not sure. Maybe it could be called upon to run static destructors and destruct heap-allocated objects. But in order to call scope guards and RAII, it would need to unwind the call stack, which could get complicated if you're trying to do it from within a function. It's much simpler not to use exit() and throw a custom exception instead. Stewart.
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
That should have been int main.
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On Thursday, December 29, 2011 23:03:23 Ashish Myles wrote:
Since D
could conceivably implement a very safe exit() without an explicit use
of Exceptions to get around the catch Exception() {} problem you
mentioned above, does it make sense to request a safer exit() feature
for D?
And how would it do that? The only way in the language to properly unwind the
stack without returning from each and every function is to throw an Exception.
If you wanted to do an exit function, it would somehow have to do the exact
same thing that happens when you throw an Exception except that it's not an
Exception and isn't caught by catch(Exception) {}. That may not be impossible,
but I expect that it would complicate things quite a bit. And scope statements
are designed around exceptions such that if you didn't throw an Exception,
they wouldn't work properly. The same goes for finally blocks. Also, what is
the correct thing to do in a situation like this
try
{
//code
}
catch(Exception e)
{
//do stuff
}
The code in the catch block assumes that it's always going to be run when the
code in the try block is not properly completed. If an exit call were made
from within the try block (be it directly in it or in a function that was
called inside it), how would the catch block be handled? Without an Exception,
it would be skipped, what's in that catch block wouldn't be run, and there
would be no proper cleanup.
The very concept of exit violates how the language functions with regards to
stack unwinding. Stack unwinding is built around how exceptions function.
exit, on the other hand, tries to avoid the whole exception thing and just
kill your program. But ultimately, you _can't_ ignore the fact that in order
to ensure proper stack unwinding, you either need to return from each function
on the stack, or throw an Exception from them. Anything else is going to fail
to unwind the stack properly.
And honestly, I would generally consider it bad practice to use an exit
function. It violates the proper flow of the program - as the issues with stack
unwinding illustrate.
If you want to do the equivalent of an exit function and have proper cleanup
occur, you really need to be throw an Exception designated for that and have
your code let it pass all the way through to main so that it can exit properly
after having unwound the stack.
- Jonathan M Davis
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On Fri, Dec 30, 2011 at 5:43 AM, Jonathan M Davis jmdavisp...@gmx.com wrote:
On Thursday, December 29, 2011 23:03:23 Ashish Myles wrote:
Since D
could conceivably implement a very safe exit() without an explicit use
of Exceptions to get around the catch Exception() {} problem you
mentioned above, does it make sense to request a safer exit() feature
for D?
And how would it do that? The only way in the language to properly unwind the
stack without returning from each and every function is to throw an Exception.
If you wanted to do an exit function, it would somehow have to do the exact
same thing that happens when you throw an Exception except that it's not an
Exception and isn't caught by catch(Exception) {}. That may not be impossible,
but I expect that it would complicate things quite a bit. And scope statements
are designed around exceptions such that if you didn't throw an Exception,
they wouldn't work properly. The same goes for finally blocks. Also, what is
the correct thing to do in a situation like this
Ok, now there are two issues here:
IMPLEMENTATION: Implementation of a safe_exit() without an explicit
Exception seems to be easy to do at the language level for a
single-threaded program -- you simply have a hidden/system class like,
say, __SystemException from which Exception derives that be comes the
base class of all throwable objects. __ExitException could then
derive from __SystemException and store the exit value. But it is not
clear how this would work for multithreaded programs, with which I
have little experience in the context of C++ exceptions. Presumably,
the __ExitException would have to be thrown in all threads and could
interrupt functions that would otherwise not throw exceptions -- I
can't say I understand all the implications.
try
{
//code
}
catch(Exception e)
{
//do stuff
}
The code in the catch block assumes that it's always going to be run when the
code in the try block is not properly completed. If an exit call were made
from within the try block (be it directly in it or in a function that was
called inside it), how would the catch block be handled? Without an Exception,
it would be skipped, what's in that catch block wouldn't be run, and there
would be no proper cleanup.
For cleanup that needs to be done no matter what the exception, I
would just use a finally{} block.
UTILITY: Now, the actual utility of having a safe exit seems to be in
question here. A common use of this is in OpenGL programs (that may be
implicitly multithreaded) where the keyboard handler exit()s when I
hit 'q' or ESC (which is quite common). Moreover, the underlying GUI
framework or other APIs being used may conceivably have multiple
threads and abstract this out for the user. Is this an unreasonable
use case for a safe exit? Or would this be too difficult to implement
cleanly?
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On Friday, December 30, 2011 10:45:43 Ashish Myles wrote:
Ok, now there are two issues here:
IMPLEMENTATION: Implementation of a safe_exit() without an explicit
Exception seems to be easy to do at the language level for a
single-threaded program -- you simply have a hidden/system class like,
say, __SystemException from which Exception derives that be comes the
base class of all throwable objects. __ExitException could then
derive from __SystemException and store the exit value. But it is not
clear how this would work for multithreaded programs, with which I
have little experience in the context of C++ exceptions. Presumably,
the __ExitException would have to be thrown in all threads and could
interrupt functions that would otherwise not throw exceptions -- I
can't say I understand all the implications.
It's more complicate than that. The base class of all throwable objects is
Throwable. Error and Exception are derived from Throwable. Destructors, finally
blocks, and scope statements are all skipped when a Throwable is thrown unless
it is derived from Exception. So, there is no proper cleanup unless an
Exception is thrown. Right now, the compiler, the runtime, and programmers can
all assume that
try
{
//code
//1
}
catch(Exception e)
{
//2
}
either #1 or #2 will be hit in that code if proper cleanup is occuring. In
fact nothrow relies on this. If you wrap a function call in a try-catch block
which catches Exception, then the function it's called in can be nothrow even
if the function being called throws an exception. If we tried to have another
exception type which was for exiting, then you'd get this weird situation
where nothrow functions _can_ throw when the program is being shutdown
properly, and that could be a big problem.
Functions in D are set up around the idea that the only way to exit a function
and have proper cleanup occur is to either return from it or have an Exception
thrown from it. You're trying to have another way added. It's not that it's
necessarily impossible, but it would likely require the redesign of several
features and would break the assumptions made by a lot of code.
For cleanup that needs to be done no matter what the exception, I
would just use a finally{} block.
Yes and no. finally gets hit whether an Exception is thrown or the try block is
exited normally, but it isn't run when a non-Exception Throwable (generally an
Error) is thrown, so it gurantees nothing on unsafe shutdown. And if you were
using exit, what would be the proper behavior? Neither the remainder of the
try block nor the catch block would be run (since exit would skip the rest of
the try block and skip the catch block entirely), which would likely break the
assumptions made by a lot of code. It would certainly break scope. All of a
sudden, you have something other than Error which won't hit scope(success) or
scope(failure) but _will_ hit scope(exit), and that something is trying to be
exiting _cleanly_ - unlike Error.
UTILITY: Now, the actual utility of having a safe exit seems to be in
question here. A common use of this is in OpenGL programs (that may be
implicitly multithreaded) where the keyboard handler exit()s when I
hit 'q' or ESC (which is quite common). Moreover, the underlying GUI
framework or other APIs being used may conceivably have multiple
threads and abstract this out for the user. Is this an unreasonable
use case for a safe exit? Or would this be too difficult to implement
cleanly?
Exceptions only affect a single thread, so they're not going to help you
terminate a multi-threaded program regardless. And to terminate another
thread, you need a way to terminate it. The only ways to do that are to tell
them to terminate themselves or to kill them. There is no way that I'm aware
of built into threads to tell them that it's time to shutdown and then let
them do it cleanly (which is what you'd need for a clean shutdown). You could
use std.concurrency to inform them to shutdown or have a shared flag which
indicates that it's time for all threads to shutdown, but you couldn't use
pthreads or the Windows equivalent to tell a thread to shutdown cleanly. So,
the only means generally available to terminate a thread is to forcibly kill
it (as C's exit does), making automatic cleanup impossible.
_Some_ cleanup can be done when exit is called using atexit and on_exit, but
the stack won't be unwound properly, so RAII, scope statements, and finally
blocks aren't going to be run properly. So, critical, global stuff can be
potentially cleaned up, but you can't get a fully clean shutdown without
actually returning or having an Exception thrown from every function in every
thread.
So, in general, the best way to handle taking down a multi-threaded
application cleanly is to message each thread (be it via std.concurrency or a
flag or whatever) which isn't going to shutdown on its own (e.g. after
finishing
some calculation)
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
Thanks, Jonathan, for your detailed answer.
Ashish
On Fri, Dec 30, 2011 at 1:41 PM, Jonathan M Davis jmdavisp...@gmx.com wrote:
On Friday, December 30, 2011 10:45:43 Ashish Myles wrote:
Ok, now there are two issues here:
IMPLEMENTATION: Implementation of a safe_exit() without an explicit
Exception seems to be easy to do at the language level for a
single-threaded program -- you simply have a hidden/system class like,
say, __SystemException from which Exception derives that be comes the
base class of all throwable objects. __ExitException could then
derive from __SystemException and store the exit value. But it is not
clear how this would work for multithreaded programs, with which I
have little experience in the context of C++ exceptions. Presumably,
the __ExitException would have to be thrown in all threads and could
interrupt functions that would otherwise not throw exceptions -- I
can't say I understand all the implications.
It's more complicate than that. The base class of all throwable objects is
Throwable. Error and Exception are derived from Throwable. Destructors,
finally
blocks, and scope statements are all skipped when a Throwable is thrown unless
it is derived from Exception. So, there is no proper cleanup unless an
Exception is thrown. Right now, the compiler, the runtime, and programmers can
all assume that
try
{
//code
//1
}
catch(Exception e)
{
//2
}
either #1 or #2 will be hit in that code if proper cleanup is occuring. In
fact nothrow relies on this. If you wrap a function call in a try-catch block
which catches Exception, then the function it's called in can be nothrow even
if the function being called throws an exception. If we tried to have another
exception type which was for exiting, then you'd get this weird situation
where nothrow functions _can_ throw when the program is being shutdown
properly, and that could be a big problem.
Functions in D are set up around the idea that the only way to exit a function
and have proper cleanup occur is to either return from it or have an Exception
thrown from it. You're trying to have another way added. It's not that it's
necessarily impossible, but it would likely require the redesign of several
features and would break the assumptions made by a lot of code.
For cleanup that needs to be done no matter what the exception, I
would just use a finally{} block.
Yes and no. finally gets hit whether an Exception is thrown or the try block
is
exited normally, but it isn't run when a non-Exception Throwable (generally an
Error) is thrown, so it gurantees nothing on unsafe shutdown. And if you were
using exit, what would be the proper behavior? Neither the remainder of the
try block nor the catch block would be run (since exit would skip the rest of
the try block and skip the catch block entirely), which would likely break the
assumptions made by a lot of code. It would certainly break scope. All of a
sudden, you have something other than Error which won't hit scope(success) or
scope(failure) but _will_ hit scope(exit), and that something is trying to be
exiting _cleanly_ - unlike Error.
UTILITY: Now, the actual utility of having a safe exit seems to be in
question here. A common use of this is in OpenGL programs (that may be
implicitly multithreaded) where the keyboard handler exit()s when I
hit 'q' or ESC (which is quite common). Moreover, the underlying GUI
framework or other APIs being used may conceivably have multiple
threads and abstract this out for the user. Is this an unreasonable
use case for a safe exit? Or would this be too difficult to implement
cleanly?
Exceptions only affect a single thread, so they're not going to help you
terminate a multi-threaded program regardless. And to terminate another
thread, you need a way to terminate it. The only ways to do that are to tell
them to terminate themselves or to kill them. There is no way that I'm aware
of built into threads to tell them that it's time to shutdown and then let
them do it cleanly (which is what you'd need for a clean shutdown). You could
use std.concurrency to inform them to shutdown or have a shared flag which
indicates that it's time for all threads to shutdown, but you couldn't use
pthreads or the Windows equivalent to tell a thread to shutdown cleanly. So,
the only means generally available to terminate a thread is to forcibly kill
it (as C's exit does), making automatic cleanup impossible.
_Some_ cleanup can be done when exit is called using atexit and on_exit, but
the stack won't be unwound properly, so RAII, scope statements, and finally
blocks aren't going to be run properly. So, critical, global stuff can be
potentially cleaned up, but you can't get a fully clean shutdown without
actually returning or having an Exception thrown from every function in every
thread.
So, in general, the best way to handle taking down a multi-threaded
application cleanly is to message
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On 2011-12-29 18:22, Jakob Ovrum wrote:
On Thursday, 29 December 2011 at 16:27:33 UTC, Ashish Myles wrote:
std.c.stdlib.exit() seems to break RAII. The code below tests this
both using a struct destructor and an explicit scope(exit) {}. Is
this an intentional feature or a bug?
import std.stdio;
import std.c.stdlib;
void main()
{
struct SafeExit {
~this() {
writeln(Safely exit with destructor.);
}
}
SafeExit safeExit;
scope(exit) { writeln(Safely exit with scope(exit).); }
scope(failure) { writeln(Safely exit with scope(failure).); }
writeln(Test if std.c.stdlib.exit() breaks RAII.);
writeln(Pre-exit!);
std.c.stdlib.exit(0);
writeln(Post-exit! Should not get here!);
}
The C runtime is beyond D's immediate control. You would have to replace
C's exit function with a custom one or make the compiler recognize calls
to it.
Calling 'exit' doesn't properly shut down the D runtime either, it's not
just constructors.
It's neither a bug or a feature. The bug is arguably in your program.
Could druntime hook up on the atexit function to run destructors and
similar when the program exits?
--
/Jacob Carlborg
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
Probably the easiest thing to do is to throw a custom exception and catch it somewhere in main() to return your status code. Unlike exit(), throwing will take care of RAII stuff.
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On Thu, Dec 29, 2011 at 1:26 PM, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Probably the easiest thing to do is to throw a custom exception and catch it somewhere in main() to return your status code. Unlike exit(), throwing will take care of RAII stuff. Thanks, Andrej. That option had occurred to me, but I figured that shouldn't be the way to do things given that most other languages have a native exit function. Given that this code transformation isn't particularly difficult (put main in a try/catch, have a custom exception storing exit code, return the exit code in the catch block), would it be reasonable to do a feature request for a D-language-supported exit()?
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On Thursday, 29 December 2011 at 16:27:33 UTC, Ashish Myles wrote:
std.c.stdlib.exit() seems to break RAII. The code below tests
this
both using a struct destructor and an explicit scope(exit) {}.
Is
this an intentional feature or a bug?
import std.stdio;
import std.c.stdlib;
void main()
{
struct SafeExit {
~this() {
writeln(Safely exit with destructor.);
}
}
SafeExit safeExit;
scope(exit) { writeln(Safely exit with scope(exit).); }
scope(failure) { writeln(Safely exit with scope(failure).);
}
writeln(Test if std.c.stdlib.exit() breaks RAII.);
writeln(Pre-exit!);
std.c.stdlib.exit(0);
writeln(Post-exit! Should not get here!);
}
The C runtime is beyond D's immediate control. You would have to
replace C's exit function with a custom one or make the compiler
recognize calls to it.
Calling 'exit' doesn't properly shut down the D runtime either,
it's not just constructors.
It's neither a bug or a feature. The bug is arguably in your
program.
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On Thursday, 29 December 2011 at 17:22:33 UTC, Jakob Ovrum wrote: Calling 'exit' doesn't properly shut down the D runtime either, it's not just constructors. I mean destructors*.
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On 12/29/2011 12:43 PM, Ashish Myles wrote: On Thu, Dec 29, 2011 at 1:26 PM, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Probably the easiest thing to do is to throw a custom exception and catch it somewhere in main() to return your status code. Unlike exit(), throwing will take care of RAII stuff. Thanks, Andrej. That option had occurred to me, but I figured that shouldn't be the way to do things given that most other languages have a native exit function. Given that this code transformation isn't particularly difficult (put main in a try/catch, have a custom exception storing exit code, return the exit code in the catch block), would it be reasonable to do a feature request for a D-language-supported exit()? Yeah, really. I'd been using the C exit() as well. Seems like a pretty fundamental feature. :O
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On Thursday, December 29, 2011 13:43:36 Ashish Myles wrote:
On Thu, Dec 29, 2011 at 1:26 PM, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
Probably the easiest thing to do is to throw a custom exception and
catch it somewhere in main() to return your status code. Unlike
exit(), throwing will take care of RAII stuff.
Thanks, Andrej. That option had occurred to me, but I figured that
shouldn't be the way to do things given that most other languages have
a native exit function. Given that this code transformation isn't
particularly difficult (put main in a try/catch, have a custom
exception storing exit code, return the exit code in the catch block),
would it be reasonable to do a feature request for a
D-language-supported exit()?
A D exit function would have to do essentially the same thing as throw an
exception and catch it in main anyway. The only way that the stack is going to
be unwound properly is if you actually unwind it. The only way in the language
to do that without actually returning from each and every function on the
stack is to throw an exception.
How many modern languages do you know of with an exit function that cleans
everything up properly? C++ won't for the same reasons that D won't. Java gets
away with it because it doesn't have destructors or scope statements or
anything else that would actually require unwinding the stack.
All a D exit function _could_ do would be to throw an exception and then have
the runtime catch it - which still wouldn't work if the programmer was foolish
enough to do something like
catch(Exception) {}
in their code. So, throwing an exception and catching it _is_ the way to do
it, and it really makes more sense if you're doing it yourself, since then
you're less likely to make that mistake and catch all Exceptions somewhere in
your code and eat the one which is supposed to exit the program.
- Jonathan M Davis
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On Thu, Dec 29, 2011 at 7:16 PM, Jonathan M Davis jmdavisp...@gmx.com wrote:
A D exit function would have to do essentially the same thing as throw an
exception and catch it in main anyway. The only way that the stack is going to
be unwound properly is if you actually unwind it. The only way in the language
to do that without actually returning from each and every function on the
stack is to throw an exception.
How many modern languages do you know of with an exit function that cleans
everything up properly? C++ won't for the same reasons that D won't. Java gets
away with it because it doesn't have destructors or scope statements or
anything else that would actually require unwinding the stack.
All a D exit function _could_ do would be to throw an exception and then have
the runtime catch it - which still wouldn't work if the programmer was foolish
enough to do something like
catch(Exception) {}
in their code. So, throwing an exception and catching it _is_ the way to do
it, and it really makes more sense if you're doing it yourself, since then
you're less likely to make that mistake and catch all Exceptions somewhere in
your code and eat the one which is supposed to exit the program.
- Jonathan M Davis
Hm...embarassingly, it didn't occur to me that C++ didn't clean up
either; but sure enough, the following code shows that exit() breaks
C++ RAII.
#include iostream
#include cstdlib
struct SafeExit {
~SafeExit() {
std::cout Safely exit with destructor. std::endl;
}
};
int main(int argc, char** argv)
{
SafeExit safeExit;
std::cout Test if std.c.stdlib.exit() breaks RAII. std::endl;
std::cout Pre-exit! std::endl;
exit(0);
std::cout Post-exit! Should not get here! std::endl;
return 0;
}
On the other hand, ruby happily *does* unwind the stack properly on exit().
def safe_exit
begin
yield
ensure
puts Safely exit with ensure.
end
end
safe_exit do
puts Test if std.c.stdlib.exit() breaks RAII.
puts Pre-exit!
exit(0);
puts Post-exit! Should not get here!
end
Honestly, I would rather have the latter robustness. While I have
always thought of abort() as being a dirty exit, I had, until now,
always thought of exit() as being very safe. Violating RAII on a
safely-intended exit() is a really Bad Thing, I would think. Since D
could conceivably implement a very safe exit() without an explicit use
of Exceptions to get around the catch Exception() {} problem you
mentioned above, does it make sense to request a safer exit() feature
for D?
Ashish
