Is there anything we can do to automatically clean up if the user hits ctrl+c on Linux?

I just had my system get messed up because I was allocating shared memory with the X server, which was released in the destructor... but that never got called because I killed the program with ctrl+c. Then the system ran out of shm handles and I had to clean that up before i could start a bunch of programs again.

Of course, a possible solution is to set up a signal handler in my own program, but even with that, tracking all the dtors that need to actually be called sounds difficult, especially as the program gets more involved.


Is it possible to either:

1) make ctrl+c throw an exception so destructor cleanup happens normally

or

2) call all the destructors and kill the program from inside a signal handler without throwing a normal exception; it doesn't matter to me that it is unrecoverable, I just need these handles cleaned up.


My backup plan is to just ignore the ctrl+c signal, or maybe set a flag in my event loop and terminate the program that way.

On Mon, Sep 30, 2013 at 03:48:07AM +0200, Adam D. Ruppe wrote:
> Is there anything we can do to automatically clean up if the user hits ctrl+c on Linux?
> 
> I just had my system get messed up because I was allocating shared memory with the X server, which was released in the destructor... but that never got called because I killed the program with ctrl+c. Then the system ran out of shm handles and I had to clean that up before i could start a bunch of programs again.
> 
> Of course, a possible solution is to set up a signal handler in my own program, but even with that, tracking all the dtors that need to actually be called sounds difficult, especially as the program gets more involved.
[...]

Well, ctrl-C can be handled, so the way I'd do it is to set up a signal handler for SIGINT and have it write something to a self-pipe read by the event handler, then the event handler can throw an Exception (which should cause dtors to run as the stack unwinds).

I've no idea how signals work in Windows so I don't know if it's even possible to have a consistent D implementation of signal-handling.


T

-- 
Change is inevitable, except from a vending machine.

On Monday, 30 September 2013 at 02:13:47 UTC, H. S. Teoh wrote:
> On Mon, Sep 30, 2013 at 03:48:07AM +0200, Adam D. Ruppe wrote:
>> Is there anything we can do to automatically clean up if the user
>> hits ctrl+c on Linux?
>> 
>> I just had my system get messed up because I was allocating shared
>> memory with the X server, which was released in the destructor...
>> but that never got called because I killed the program with ctrl+c.
>> Then the system ran out of shm handles and I had to clean that up
>> before i could start a bunch of programs again.
>> 
>> Of course, a possible solution is to set up a signal handler in my
>> own program, but even with that, tracking all the dtors that need to
>> actually be called sounds difficult, especially as the program gets
>> more involved.
> [...]
>
> Well, ctrl-C can be handled, so the way I'd do it is to set up a signal
> handler for SIGINT and have it write something to a self-pipe read by
> the event handler, then the event handler can throw an Exception (which
> should cause dtors to run as the stack unwinds).
>
> I've no idea how signals work in Windows so I don't know if it's even
> possible to have a consistent D implementation of signal-handling.
>
>
> T

Windows uses kernel level exceptions for some signals, known as Structured Exception Handling. For others, callback handlers are used instead, similar to signal handlers.

http://msdn.microsoft.com/library/windows/desktop/ms680657.aspx

signal() is available,

http://msdn.microsoft.com/en-us/library/xdkz3x12%28v=vs.110%29.aspx

However, since I never used signal on Windows, here is the specific Windows API for the same purpose,

http://msdn.microsoft.com/en-us/library/ms686016%28VS.85%29.aspx

--
Paulo

On Monday, 30 September 2013 at 01:48:09 UTC, Adam D. Ruppe wrote:
> Is there anything we can do to automatically clean up if the user hits ctrl+c on Linux?
>
> I just had my system get messed up because I was allocating shared memory with the X server, which was released in the destructor... but that never got called because I killed the program with ctrl+c. Then the system ran out of shm handles and I had to clean that up before i could start a bunch of programs again.
>
> Of course, a possible solution is to set up a signal handler in my own program, but even with that, tracking all the dtors that need to actually be called sounds difficult, especially as the program gets more involved.
>
>
> Is it possible to either:
>
> 1) make ctrl+c throw an exception so destructor cleanup happens normally
>
> or
>
> 2) call all the destructors and kill the program from inside a signal handler without throwing a normal exception; it doesn't matter to me that it is unrecoverable, I just need these handles cleaned up.
>
>
> My backup plan is to just ignore the ctrl+c signal, or maybe set a flag in my event loop and terminate the program that way.
There is a similar thread on this topic. Maybe he can help you, especially the last post:
http://forum.dlang.org/thread/crviwhvbfruxfnwawirs@forum.dlang.org

On Monday, 30 September 2013 at 01:48:09 UTC, Adam D. Ruppe wrote:
> Is there anything we can do to automatically clean up if the user hits ctrl+c on Linux?
(...)

I believe vibe.d does this.

On Monday, 30 September 2013 at 02:13:47 UTC, H. S. Teoh wrote:
> Well, ctrl-C can be handled, so the way I'd do it is to set up a signal
> handler for SIGINT and have it write something to a self-pipe read by
> the event handler, then the event handler can throw an Exception (which
> should cause dtors to run as the stack unwinds).
>

No you can't.

But you somehow can, if you want to use some black magic : http://www.deadalnix.me/2012/03/24/get-an-exception-from-a-segfault-on-linux-x86-and-x86_64-using-some-black-magic/

On Mon, Sep 30, 2013 at 08:44:36PM +0200, deadalnix wrote:
> On Monday, 30 September 2013 at 02:13:47 UTC, H. S. Teoh wrote:
> >Well, ctrl-C can be handled, so the way I'd do it is to set up a signal handler for SIGINT and have it write something to a self-pipe read by the event handler, then the event handler can throw an Exception (which should cause dtors to run as the stack unwinds).
> >
> 
> No you can't.
> 
> But you somehow can, if you want to use some black magic : http://www.deadalnix.me/2012/03/24/get-an-exception-from-a-segfault-on-linux-x86-and-x86_64-using-some-black-magic/

We were talking about SIGINT, not SIGSEGV.


T

-- 
Unix is my IDE. -- Justin Whear

On Mon, 30 Sep 2013 09:49:12 +0200
"Namespace" <rswhite4@googlemail.com> wrote:

> On Monday, 30 September 2013 at 01:48:09 UTC, Adam D. Ruppe wrote:
> > Is there anything we can do to automatically clean up if the user hits ctrl+c on Linux?
> >
> There is a similar thread on this topic. Maybe he can help you, especially the last post: http://forum.dlang.org/thread/crviwhvbfruxfnwawirs@forum.dlang.org

You know, this sounds like something that really should fall squarely in the category of "do the right thing by default". Is there any reason druntime can't be made to handle this better by default?

On Tuesday, 1 October 2013 at 03:58:04 UTC, Nick Sabalausky wrote:
> On Mon, 30 Sep 2013 09:49:12 +0200
> "Namespace" <rswhite4@googlemail.com> wrote:
>
>> On Monday, 30 September 2013 at 01:48:09 UTC, Adam D. Ruppe wrote:
>> > Is there anything we can do to automatically clean up if the user hits ctrl+c on Linux?
>> >
>> There is a similar thread on this topic. Maybe he can help you, especially the last post:
>> http://forum.dlang.org/thread/crviwhvbfruxfnwawirs@forum.dlang.org
>
> You know, this sounds like something that really should fall squarely in
> the category of "do the right thing by default". Is there any reason
> druntime can't be made to handle this better by default?

I would say the main reason is that anyone can replace the current set of signals, thus breaking what might be druntime's signal handling.

--
Paulo

On 2013-10-01 06:54, PauloPinto wrote:

> I would say the main reason is that anyone can replace the current set
> of signals, thus breaking what might be druntime's signal handling.

If druntime has a default signal handler and the user replaces that. It's up to the user to call the original signal handler so everything is properly destructed/finalized.

It's the same problem with the GC and all the other handlers that druntime has that the user can override.

I would consider these very advanced features and not something a user should be fiddling with every day.

-- 
/Jacob Carlborg