>Doesn't have native signal handling APIs
Oof. That's rough, rust friends.

>>105709230 (OP)
It has signal handling ability. It's called a match expression.
for sig in signals.forever() {
match sig {
SIGINT => {
println!("Received SIGINT (Ctrl+C). Shutting down...");
break;
}
SIGTERM => {
println!("Received SIGTERM. Shutting down...");
break;
}
_ => println!("Received unknown signal: {}", sig),
}
}

>>105709414
That's just a less readable swith.

>>105709422
If match expression is unreadable to you, consider a different hobby.

>>105709414
Ok, now register the signal handler :)

>>105709433
Sure :)
use signal_hook_registry::{register, unregister};
use std::sync::atomic::{AtomicBool, Ordering};
use std::sync::Arc;
use tokio::time::{sleep, Duration};

#[tokio::main]
async fn main() {
// Shared flag to indicate shutdown should happen
let running = Arc::new(AtomicBool::new(true));
let r = running.clone();

// Register handler for SIGINT (Ctrl+C)
let _handler_sigint = register(signal_hook_registry::SIGINT, move || {
println!("Received SIGINT. Shutting down...");
r.store(false, Ordering::SeqCst);
}).expect("Failed to register SIGINT handler");

// Register handler for SIGTERM
let _handler_sigterm = register(signal_hook_registry::SIGTERM, move || {
println!("Received SIGTERM. Shutting down...");
running.store(false, Ordering::SeqCst);
}).expect("Failed to register SIGTERM handler");

println!("Waiting for signals... (try Ctrl+C or sending SIGTERM)");

// Simulate work while checking the running flag
while running.load(Ordering::SeqCst) {
println!("Working...");
sleep(Duration::from_secs(1)).await;
}

println!("Goodbye!");
}

>>105709441
>third party libraries
>Needing tokio to handle signals
Haha, please kill yourself, ok? :)

>>105709447
>>third party libraries
What third party? signal hook is written in Rust
>Needing tokio to handle signals
No not really. To handle signals you only need a match expression.
>Haha, please kill yourself, ok? :)
No, are you mad? :)

>>105709441
>yes, you need a whole async runtime to use a core os functionality in this blazingly fast systems programming language

>>105709463
Do you understand the concept of handling signals asynchronously?

>>105709462
Wow, you're so clever! Thanks for proving me right though :)

>>105709470
>Wow, you're so clever!
I know :)
>Thanks for proving me right t
Whatever lets you sleep at night :)

>>105709468
Is there any reason to slap on a runtime that's pretty much as large as Go's to achieve this task instead of just using threads from the stdlib?

>>105709497
Raw threads aren't virtual, you can use threadpools. But async makes sense too.

>>105709497
Yes, the reason is that Rust literally doesn't have signal handling APIs in the core lib, and there are pretty much no worthwhile signal handling crates that aren't async bloat. Your best bet is to just use libc directly.

>>105709230 (OP)
you posted this yesterday

>>105709528
I will post it tomorrow too, just so you know.

>>105709497
Crabs unironically believe it is undefined behavior having multiple threads listening for signals. Please understand.

>>105709518
>signal handling APIs in the core
core is meant to work without an OS. If you are handling signals, you already have an OS and thus it makes no sense to put it in the core lib :)

>>105709230 (OP)
>signal handling
Use case?

>>105709552
Sounds like you are hearing voices in your head.
Consider medication :)

>>105709536
Yeah you should try again. Your thread got train-wrecked today.

>>105709554
The standard library has file handling APIs. It also has several OS specific modules. There is no reason not to have signal handling APIs, even if its just a wrapper on signal.h. It also has several unsafe functions, so that isn't an excuse either.

>>105709613
>First rust post has to pull Tokio to achieve basic signal handling
:)

>>105709633
I don't see any tokio in first post :)

>>105709655
You don't see anything in the first post because that code doesn't even compile.

>>105709667
That code doest not compile because it does not setup the main function and signals iterator
But still no tokio tough :)

>>105709671
>Blah blah blah
Still doesn't compile though.

>>105709678
If you aren't able to setup the main function and the signals iterator, it's simply a skill issue :)

>>105709694
Register the signal handler and mask. Apparently your Tokio example wasn't it, so go on. Everyone's still waiting anon.

>>105709710
>Apparently your Tokio example wasn't it,
Who says so? :)

>>105709230 (OP)
why does everything have to be so complicated in rustland?

That whole thread

>>105709447
You people keep talking about how you want to avoid tokio, you don't actually care about "bloat" do you? You just don't want to tokio because it's written by a trans woman, is that it?

>>105710964
This is why rust will never be taken seriously.

>>105709497
Yes, you won't understand it though, because you don't understand what async is

>>105710964
>you don't actually care about "bloat" do you?
Why wouldn't someone care about bloat?
>You just don't want to tokio because it's written because it's written by a trans woman, is that it?
Are you a troll? The original author is Carl Lerche, and he's not trans. I'm trans and never would have known that without looking it up.

>>105711008
>this is why
Why? Rust is moving forward with Tokio being the one true async runtime, it would even be intergrated into the stdlib if it weren't for the fact that they can't update stdlib as fast

>>105711046
Because tokio is bloat and async has inherent overhead, your shitty "futures" which is ironic, because rust has no future, not even singular one, are extra bloat with ZERO benefit.

>>105711041
>The original author is Carl Lerche
He rarely contributes nowadays into tokio itself, the current primary developer is trans

>>105711056
>rust has no future
What's gonna replace it then? Nobody wants to write C++ anymore

>>105711061
I doubt the reason someone who criticizes the use of Tokio as bloat is actually doing it because the main contributor is trans, though. Probably only someone very obsessed would even know and care that much. It might just be that they genuinely think it's bloated.

>>105709463
look ma
no async
use signal_hook_registry::register;
use std::time::Duration;
use std::sync::atomic::{AtomicBool, Ordering};
use std::sync::Arc;
use std::thread;

fn main() {
// Shared flag to indicate shutdown should happen
let running = Arc::new(AtomicBool::new(true));

unsafe {
let r = running.clone();
// Register handler for SIGINT (Ctrl+C)
let _handler_sigint = register(libc::SIGINT, move || {
println!("Received SIGINT. Shutting down...");
r.store(false, Ordering::SeqCst);
}).expect("Failed to register SIGINT handler");

let r = running.clone();
// Register handler for SIGTERM
let _handler_sigterm = register(libc::SIGTERM, move || {
println!("Received SIGTERM. Shutting down...");
r.store(false, Ordering::SeqCst);
}).expect("Failed to register SIGTERM handler");
}

println!("Waiting for signals... (try Ctrl+C or sending SIGTERM)");

// Simulate work while checking the running flag
while running.load(Ordering::SeqCst) {
println!("Working...");
thread::sleep(Duration::from_secs(1));
}

println!("Goodbye!");
}

But oh god IT'S UNSAFE!!!!

>>105711485
>libc::

>>105711524
s/libc::SIGINT/2/
Works the same way. This function just takes the an integer parameter.

>>105709441
this is retardedly convoluted to the point i'm hoping it's something an LLM shat.
neither async nor tokio are relevant for starters. but even if your main is async/tokio, you don't need more than something like this:
use signal_hook::consts::signal::*;
use futures_lite::stream::StreamExt;
use signal_hook_tokio::Signals;

async fn handle_signals(signals: Signals) {
let mut signals = signals.fuse();
while let Some(signal) = signals.next().await {
match signal {
SIGTERM | SIGINT | SIGQUIT => {
// handle code here
// exit process if you want
// std::process::exit(1);
},
_ => (), // ignored
}
}
}

#[tokio::main]
async fn main() -> YourResultType<()> {
let signals = Signals::new(&[SIGTERM, SIGINT, SIGQUIT])?;
let handle = signals.handle();
let signals_task = tokio::task::spawn(handle_signals(signals));

// main code
}

>>105711611 (Me)

and of course, after the main code:

// main code
handle.close();
signals_task.await?

>>105711485
You still have to pull signal_hook_registry. Is that maintained by the rust maintainers? If not, it's unreliable and misses the point. If it is I'll be happy.

I'm actually not against splitting basic STD functionality into different crates, provided they
1. Are actually referenced in the documentation so they're easy to find, and
2. Are maintaned by the same people who maintains the std lib, and not a random dude who will just burn out in two years and leave the whole thing hanging
Of course, actually explaining to a rustie why these things matter is impossible.

>>105711697
nta. but code is not a running machine that requires constant maintenance. in simple cases such these, if it works, it works. and it's not like libc implementations see a lot of development (besides plugging CVE's and finding new ways to make allocations slower in the name of "security").
maybe you get burned out by major compiler updates breaking code all the time, or maybe unexpected API and/or ABI breakage is always keeping you busy, but such experiences do not necessarily translate to other languages/ecosystems.

>>105709230 (OP)
Signal handling is not a universal feature of computers or operating systems, so it doesn't belong in the language. It belongs in a platform-specific library.

>>105711524
Yes, because those "signals" are a C feature defined in libc.