Artem Medvedev
Artem Medvedev
The code, you're referring to, doesn't look like a reason. Yes, `loop` is stopped once `signal` is received. But any accepted connection is spawned in separate task (`tokio::spawn`), and there...
However I see possible race condition 🤔 - `notify_waiters()` will notify only already registered waiters Thus if it's called after `alive_connections.load(Ordering::Acquire) > 0`, but before `notify.notified()` - it might be...
Yes, I completely agree and also thought about something like this approach to have a wrapper for these cases. But didn't want to mix this up with the fix. Just...
Ok, I implemented a wrapper for spawned tasks. Seems reasonable to provide this right away (diff also smaller now) It simplified the code and now we provides a good interface...
cc @alamb @tustvold
Subjectively, but I find the new interface less boilerplate - you have one wrapper which spawns and wraps the task instead of dealing with `JoinHandles` + `AbortOnDrop` + `tokio::spawn` But...
> deprecate the methods that take a JoinHandle down the line But a lot of usages were already refactored here https://github.com/apache/arrow-datafusion/pull/6750 🤔 I thought it's a target to disallow working...
The naming is definitely negotiable, I'm not making any claims to the truth with the current version. Subjectively, it looks like this: we `spawn` a task and then we have...
>I wonder if you want to put an "exclude" type lint in to prevent people from accidentally using std::time::Instant Unfortunately, I think it's not possible "as is" for this case,...