Allow suppressing panics.

[anp]

This makes it possible to incrementally adopt tracing-mutex in a library shared by many binaries in the same project without having to fix all potential deadlocks in all binaries at once. The binaries that don't yet have proper lock hygeine can opt-out of real enforcement until their deadlocks are addressed.

[bertptrs]

Hi, thank you for your contribution. I see your use case and while I would've appreciated an issue before the implementation so we could hash out some details, I think your design is pretty sound.

Aside from some general review comments, I have one concern, whether this wouldn't blow up your program's output if this is a code path that's hit fairly often. Panics have the inherent property that they will terminate the current course of action, avoiding hot loops causing the issue repeatedly. I'm not using this library in practice despite originally thinking I would, so I don't know how that shakes out in practice. Happy to hear your thoughts.

Also, before this PR is merged, could you add a small changelog entry?

[bertptrs]

Could you remove this example? It is simply a carbon copy of the main example, with a single line added.

[anp]

Sure thing. I agree it's not very nice.

I used it while iterating to manually test the panic suppression, I'll see if I can figure out a real test to leave behind.

[bertptrs]

I'm not sure this should be a boolean. Printing to stderr, as implemented here, is but one of many "reasonable" things one could do.

I'd probably want to go with an enum instead. Prior art in atomic_enum (not suggesting to use that crate for storing a single enum, that's overkill) suggests that this is not that difficult.

[anp]

Good point. What do you think about a custom callback API like https://doc.rust-lang.org/std/panic/fn.set_hook.html? That way users would have full control over what happens, and the default callback could be the current panic behavior.

[bertptrs]

That's a much better idea than what I had in mind; I figured a large enum with all of the options available but that involves a bunch of conditional compilation for the initial few things I thought of (logging/tracing facade support) came to mind.

Let's go with that. I guess we'd want a Mutex<Box<dyn FnMut + Send>> or Mutex<fn>? The former seems more flexible, but the latter is easier to initialize.

[anp]

I see your use case and while I would've appreciated an issue before the implementation so we could hash out some details, I think your design is pretty sound.

Thanks! No worries, happy to discuss on issues beforehand in the future and I'm OK throwing away this code based on feedback. Please don't feel pressured to accept just because the PR exists!

Aside from some general review comments, I have one concern, whether this wouldn't blow up your program's output if this is a code path that's hit fairly often.

This is definitely an issue. I've actually rolled this change out experimentally at work in some debug builds and yes it creates a lot of spam in the logs when a lock cycle is exercised frequently. Given the severity of a bug that a lock cycle represents it hasn't (yet) been unpopular but I could see a lot of scenarios where it'd be an issue. I think if the crate exposes a custom callback hook it might be easy to leave solutions to this up to users in case there are different approaches for different use cases/contexts.

If you're not sure about offering a custom hook API, it might be reasonable to rate limit the messages printed? Or maybe store a map of cycles seen and only print each one once?

[bertptrs]

I like the idea of the custom hook. As I highlighted in my review comment, I'm not sure of the type for that hook (either FnMut stored in a Box or a fn), but let's go with the former first. I think it'd be reasonably doable to implement your rate-limiting idea with an FnMut. It would also allow people to implement their logging thing.

With that, I'd just like to ask you to quickly rebase your PR and run a cargo fmt. It looks good otherwise.