Ctrl + c not running Drop traits is also annoying

what's the point then, eh

Sure. But you probably can impliment the atexit function or at least register the signal handler to do it.

Well, they're only run when the code can actually finish executing. Ctrl+C nukes the process

@12bitfloat BUT WHAT IF I WANNA DROP CONNECTIONS NICELY OR SAVE DATA TO A FILE

@12bitfloat ok evidently tokio has a ctrl_c hook. you gotta spawn a new thread and wait for the hook and then you can do your thing

but also why is it so ugly. like how is this not ugly

and then I can't just have that call drop, because it'll have conflicts due to async borrowing rules

awful lot of work for something so simple

@jestdotty Just don't assume drop to run. Explicitely call your logic to log/save whatever you want to save on exit

And that's not a Rust thing, that's just in general. In Java there's no guarentee finalize runs. In C++ theres no guarentee deconstructors or catch blocks run

Just how it works I guess

@12bitfloat well then Drop is useless as a trait, ayyo

@jestdotty It's not useless, it does what it's supposed to

Fundamentally the issue is that Drop calls are baked into the produced machine code. When you Ctrl+C the program stops executing the normal code. It's not feasible for languages to hook that, figure out where the program stopped, have some sort of stack map to know where everything is, look up which values still exist, query the locations and run the drop impls remotely

That's just not reasonable to expect

@12bitfloat *expects it anyway* la la la la

I think it should be possible to catch a HUP and convert it into a program-specific cancelation event, no?

@jestdotty, is there no way to catch/is there no "SIGINT" signal raised? That's how I'm handling it on the c++ side

std::signal(SIGINT, signalHandle);

@BordedDev It is possible and that's how you'd generally do that. There's even a crate called ctrlc which does exactly that lol