Accessing storage via Pointer

[vitvakatu]

At this moment there is no way to access Storage from Pointer to that Storage, despite Storage is still in memory. For example:

let storage = Storage::new();
let ptr = storage.write().create(10 as i32);
drop(storage); // storage is dropped, but stand in memory, 
// because there is Pointer that points at it.

I suggest new method for Pointer, that will return Storage pointed by it

[kvark]

After a bit of elaboration on Gitter, we decided to not expose it. Leaving the issue open for further discussion.

[vitvakatu]

It's no more possible with current implementation (see #25)

[kvark]

I'm thinking if something like this would be feasible:

struct FatPointer<T> {
  pub storage: Arc<spin::Mutex<Storage<T>>,
  pub pointer: Pointer<T>,
}

With this, we could have helper methods (even Deref?) to access the data directly, provided that everything would need to keep Arc<Mutex<Storage>>. Special care needs to be taken of possible deadlocks (which are inevitable).

[vitvakatu]

Do we really need it? Well, it can be useful in some scenario, but if we mix FatPointers with the regular ones, it will have no sense - you'll still need Storage. Using FatPointers alone is better, but the performance will be awful And avoiding deadlocks will be extremely tricky. All in all, I'm not against, we just need to investigate this topic and act carefully.

[TyOverby]

As a casual observer (I'm planning on using Froggy at a later date), I mostly take issue with the name. I'd replace it with MutexPointer so that they know just how bad of an idea it is.

That said, I think that if people use these, there's going to be a lot of wasted time dealing with deadlocks.

[kvark]

yeah, I agree completely. Just don't want to take the idea off the table just yet. See, the (original) promise of Froggy was that you can work with it as having a regular OOP program. Forcing the user to always have Storage available when they need to use a pointer makes it not quite OOP. Having an option of FatPointer would potentially solve that, if only we can make it work without dead-locking.