Expand support for externally provided synchronization

[kpreid]

Ideally, it would be possible to use all nosy types implementing Sync without depending on std.

#19 proposed and #20 implemented adding RawNotifier towards this goal, but it isn’t very complete. To get the full set of nosy functionality still has to reimplement their own:

• Notifier wrapper around RawNotifier, in order to provide a Listen implementation
• Buffer
• NotifierForwarder
• StoreLock
• Cell and CellWithLocal

In the particular case of Cell, a possible option here would be to provide a generic interface which allows atomic cell values — i.e. a cell that contains an AtomicU32 instead of a Mutex<u32> — which is more efficient and naturally generalizes to arbitrary mutexes. However, I haven’t thought of any comparably tidy solutions for Notifier, yet.

[kpreid]

In the particular case of Cell, a possible option here would be to provide a generic interface …

I have a working implementation of the trait for nosy::Cell, though, since that trait is implemented itself for core::cell::Cell and is kind of a “Cell-ish” trait, it highlights that nosy::Cell is perhaps a poor choice of name; nosy::Cell is more precisely a sort of CellishWithNotifications but that name doesn't work.

It’s trickier to provide such a trait for the rest of the Mutex/RwLock uses because, in general, they have “hidden implementation details” structures (even Notifier is not strictly a RawNotifier wrapper) and so it seems like the trait would have to be an awkward GAT type family thing:

impl RwLockIsh for RwLock<()> {
    type Lock<T> = RwLock<T>;
    type Guard<'a T> = RwLockReadGuard<T>;
    fn read<T>(lock: &Self::Lock<T>) -> Self::Guard<'_, T> {...}
    ...
}

[kpreid]

Note that once all mutexes are pluggable, the "sync" feature (which changes the implementation of Notifier etc. to be Sync via using std) may no longer have a purpose, since it'd be up to the caller to choose the Sync implementation instead.

[kpreid]

#43 adds trait LoadStore to resolve the Cell part of the problem.

I'm now exploring making the remaining Mutexes and RwLocks pluggable by using lock_api (which has the disadvantage of not allowing use of std::sync::Mutex, but does solve the abovementioned type family problem) and adding a lock implementation generic parameter everywhere it is needed.

Notably awkward so far: Source::flatten() produces a thing that contains a Notifier, so it needs a generic. This implies that you would need to write some_source.flatten::<MyRawRwLock>(), which is an unpleasant mix of high-level and low-level.

[kpreid]

In the specific case of StoreLock (which contains a Mutex), I wonder if it’s possible to entirely replace it with trait implementations such that if T: Store then Weak<Mutex<T>>: Listener.

[kpreid]

Further thoughts on that: The reason why I have generally had types like struct SomeListener(Weak<Mutex<State>>) is because the Listener implementation is doing two jobs:

1. Weak::upgrade(), to detect when the listener is no longer needed.
2. Mutex::lock(), to transform & access into &mut access.

If we want to support separately provided mutexes for StoreLock and similar cases, then one way to do it is to have a trait separate from Listener to be implemented for the mutex, which unlike Listener does not have an alive: bool to report whether the listener is no longer needed. This trait would sit in the middle between Listener and Store, so we have:

impl<T: NewTrait> Listener for Weak<T> {...}
impl<T: Store> NewTrait for Mutex<T> {...} // and RefCell, and user-provided mutexes

It would be defined like:

trait NewTrait {
    fn receive(&self, messages: &[M]);
}

i.e. identical to Listener except for the returned bool. It would be nice if this was just some kind of generic variation of Listener, but I can’t think of a clean way to do that, and keeping them separate traits is probably better for avoiding implementation overlaps.

Adding this trait would also reduce the number of repeated implementations of Weak::upgrade() followed by returning false when it fails.

I just need a name for this new trait.

[kpreid]

PR #46 (not merged yet) introduces the above-described trait under the placeholder name NotSelfAwareListener. That addresses StoreLock by allowing it to be either replaced or reimplemented easily; the big remaining problem is Notifier. Ideas:

1. Introduce a trait CanBeLockedToDerefToRawNotifier that Buffer and NotifierForwarder are generic over, and which is implemented by Notifier and can be implemented for anything that can behave like a Mutex<RawNotifier>.

   • Would need some way to implement Notifier::close(); perhaps adding the close functionality to RawNotifier.
   • Disadvantage: only helps Notifier.
   • Benefit is that Buffer and NotifierForwarder would have fewer generics; they would have a single Notifier parameter instead of Message and Listener.

2. Use lock_api — narrower applicability but less of “add extremely specific traits to the API to solve one problem each”. This would mean that Listener, Buffer, and NotifierForwarder gain another generic parameter.

3. Find a lock-free, OS-independent data structure that can implement Notifier’s list. I am not sure this is possible.

[kpreid]

“Sleeping on” the problem of naming NotSelfAwareListener, one noteworthy fact is that it is completely identical to Store except for the receiver type. Therefore, we could do one of these things:

• Rename it to StoreRef and rename Store to StoreMut:
• Make one Store trait implemented for both kinds of references. (This feels like the required HRTBs might cause trouble).

In a different direction, we could unify it with the Listener trait, by adding a generic parameter which controls the return type:

trait Listener<M>: fmt::Debug {
    type Report; // should be either () or bool
    fn receive(&self, messages: &[M]) -> Self::Report;
    ...
}

But this would be clunky to no clear benefit. I think that for now, I will try working with StoreRef + StoreMut and see how I like it.

[kpreid]

Another question is whether NotSelfAwareListener/StoreRef should have a boolean or maybe Result return type, so that they are allowed to communicate “considering my current state, I no longer wish to receive any messages”.

This would, for example, allow a listener to be dropped upon mutex poisoning (if desired, not mandatory). It might also help with some cases like #5 where the state of the other end of the relationship indicates it’s finished, even though the weak reference is still alive, but I am not sure exactly what case that would be.