Crystal: Catch CTRL+C interrupt?

[stugol]

Is there a way to intercept the CTRL+C interrupt and run clean shutdown logic?

[refi64]

LibC.signal Signal::INT.value, ->(s : Int32) {
  puts "CTRL-C handler here!"
  exit
}

0.to 100000 { puts 123 }

In most cases, though, you should override finalize in the classes that need cleanup.

[will]

There is a bit nicer support without having to go to LibC manually

Signal::INT.trap do
  puts "CTRL-C handler here!"
  exit
end

1000000.times do
  print '.'
  sleep 0.01
end

[stugol]

@kirbyfan64: finalize is broken. See https://play.crystal-lang.org/#/r/oyd

[stugol]

@will Thank you.

[refi64]

I think that's a bug...

[stugol]

Unless it's only supposed to work if and when the GC does a cleanup, like in .NET. In other words, "sometime maybe never", which makes an utter mockery of the very idea of a finaliser.

.NET could have been so much better.

[stugol]

Rust got object lifetimes right. Shame it doesn't support function overloading. Also shame it replaced perfectly good symbolic notation with stupid words.

[asterite]

finalize runs when the GC collects an object. You should only use it to free resources, and never allocate memory there (so raising an exception is not good)

[stugol]

There are times when finalize is never called, though - e.g. on program exit. So why even bother having a finaliser? It's dumb to have a mechanism that only works "some of the time". Know how often I write a finaliser in .NET? _Never!_ Because they're pointless.

Can you give me one case when an unreliable finaliser is actually useful?

[will]

Calling a required memory-freeing function in a linked c library.

On Saturday, December 26, 2015, stugol [email protected] wrote:

There are times when finalize is never called, though - e.g. on program
exit. So why even bother having a finaliser? It's dumb to have a mechanism
that only works "some of the time". Know how often I write a finaliser in
.NET? _Never!_ Because they're pointless.

Can you give me one case when an unreliable finaliser is actually useful?

—
Reply to this email directly or view it on GitHub
https://github.com/manastech/crystal/issues/1968#issuecomment-167355575.

[stugol]

You can't rely on it actually being called though. So what's the point?

[stugol]

Granted, if you're only freeing memory, I guess it makes sense. If the GC doesn't run, presumably you have plenty of memory left. But there are loads of things _other than_ memory that might need releasing, and a sometime-maybe-never finaliser is utterly useless for all of them.

[refi64]

On most modern systems, all memory is automatically freed when the program terminates.

[ysbaddaden]

Lets keep calm. We almost never need to use the finalize method in regular code. It's only usage is to reclaim memory the GC can't know about, which usually means when creating a binding to an external C library.

For instance in the postgresql driver, the Result class keeps a reference to the libpq result, which is freed with PQclear(result) in the finalize method.

You can't expect finalize to be reliably called for anything that doesn't free memory, since this is only called by the GC, and the GC doesn't run at exit, since the OS will free the memory by itself.

You need something else, like at_exit {} and/or a coroutine that will regularly clear what you need to.

[stugol]

@kirbyfan64 I know. That's why nondeterminate finalisers are so pointless.

[asterite]

Closing this because the answer is answered (please use our Google Groups if you want to discuss these things, but finalizers work like that in Java, C#, D and many other languages and people do some really good programs in them, I don't think finalizers are broken).