search

slog-rs / async

Asynchronous drain for slog-rs v2
Apache License 2.0
28 stars 24 forks source link

Replace crossbeam-channel by flume #23

Open zazabe opened 3 years ago

zazabe commented 3 years ago

Replace crossbeam-channel by flume, which is coming with some advantages, see https://github.com/zesterer/flume#why-flume.

zazabe commented 3 years ago

not sure if i'm right, but it seems flume::Sender/Reciever are not unwind-safe, because they are dependent on Spinlock, with no lock poisoning.

So it doesn't work well with slog::SendSyncUnwindSafeDrain trait...

vorner commented 3 years ago

Aren't spin locks kind of a bad idea in general?

zazabe commented 3 years ago

Not sure, maybe they have good reasons to use spinlocks ...

I created this PR because we found some performance issues with slog::async + crossbeam-channel.
For our use-case, with multiple log producers, channel send long-tail performance can be quite bad, so we decided to downgrade slog-async to 0.2.3 for now, which uses std::mpsc.
According to our benchmarks, flume doesn't have this perf degradation.

But it's probably more a crossbeam issue, i'll open a ticket there.

vorner commented 3 years ago

Not sure, maybe they have good reasons to use spinlocks ...

They are generally quite fast because they are simple and they don't need OS support. But if the thread is ever preempted while the lock is held, other threads will burn CPU for the whole scheduler tick (and even yielding to the OS scheduler doesn't have to help, if enough of them are spinning, they will keep turns). So in a sense, they can be faster, but they also have much more severe „failure“ mode. That's why eg. parking_lot spins for few turns, but then suspends on a real OS-backed mutex.

I guess the problem with crossbeam is that it runs kind of GC thing from time to time, which takes time on one of the CPUs. But I'd be wary of putting a spinlock into logging for the above reason.

dpc commented 3 years ago

Well... I'm not sure what to do about it. :D

vorner commented 3 years ago

OK, I've had a look at flume and it seems not to be using the spin lock as a mutex: https://github.com/zesterer/flume/issues/29#issuecomment-641530555. So my fear of spin-locks here is probably not warranted.

dpc commented 3 years ago

So... all agree that flume is better? :D

Techcable commented 2 years ago

Is this still a draft?

dpc commented 2 years ago

Could be a config (feature) option.

njam commented 2 years ago

Just to add that @zazabe and I eventually settled on using std::sync::mpsc and not flume because the performance was better with mpsc for our use case.

See some benchmark data here: https://github.com/slog-rs/async/issues/21#issuecomment-762736542

Techcable commented 2 years ago

Maybe we should put both flume and crossbeam behind feature flags, that way people can pick whatever they want.....