Support blocking and non-blocking operations on the same Mutex

[joshtriplett]

Add lock_blocking and lock_arc_blocking methods to allow sharing the same lock between blocking and non-blocking code.

Introduce a helper macro to avoid duplicating the code of the acquire_slow method.

[zeenix]

Thanks @joshtriplett ! LGTM. Could see check why the mini test is failing?

[zeenix]

Thanks @joshtriplett ! LGTM. Could see check why the mini test is failing?

Ah nm. @taiki-e already fixed it: https://github.com/smol-rs/async-lock/pull/26 . Can you rebase?

[notgull]

I'm a bit concerned about this. If this crate moves to a different backing implementation of synchronization, this may include a higher burden of porting.

[joshtriplett]

@zeenix Rebased.

@notgull Support for both blocking and non-blocking seems fairly fundamental to event-listener, and I think it's an important primitive for bridging between sync and async code. This is the kind of thing I'm hoping to see in the standard library in the future: not two completely independent lock types, but one lock type that works in both sync and async code.

[notgull]

I see. I wonder if this could be done for async-channel, since that is also backed by event-listener.

[joshtriplett]

@notgull I very much hope so!

[zeenix]

@smol-rs/admins so any objections in merging this?

[taiki-e]

I think a caveat like "calling this method on async code may cause deadlock" would be nice. Otherwise LGTM.

I wonder if this could be done for async-channel, since that is also backed by event-listener.

I would accept a PR that does this.

[dignifiedquire]

What's needed for getting this in?

It would also be super useful to have this for RwLock.

[notgull]

What's needed for getting this in?

It would also be super useful to have this for RwLock.

It would need a rebase, among other things. I've opened #39 as a replacement that also implements blocking ops for the other lock types.

[notgull]

Closed by #56