discussion: Motivation for Drop strong_count <= 2 check?

[timcharper]

In https://github.com/viperscape/rust-promise/blob/master/src/promise.rs#L98, I'm curious to know your motivation for this.

If you only have 2 instances, and instance #2 drops, but then, later, instance #1 clones, then it seems you could prematurely (and erroneously) fulfill the promise.

Is my thinking off here?

Thanks

[viperscape]

It's not essential, but helpful. So originally this was because I wanted a way to communicate to the Promiser that the promise is now without potential subscribers. The promiser thread may clone the promise, spin the Promisee off to a new thread and eventually try and fulfill the promise; all without knowing that the Promisee had expired. If this happens you'll be pushing data to a blackhole and never know the result of it. If the Promiser needs to re-clone the promise, as in your instance, it makes sense to just create a new promise at that point; otherwise we lose this bit of knowledge when a Promisee panics, for instance. Hope that clears it up!

Thanks for looking in to the library, and appreciate your help on it. Also give oyashio a looksee, if you have a chance.

[viperscape]

Now that I think on it, this probably comes at a cost; it may be beneficial to check this in a benchmark, somehow (with one variation being without the promisee drop method)

[timcharper]

Thanks for the explanation. I can understand the motivation better. My senses tell me there is a race condition here, but I'm failing to find a sensible example.

In this case, the Init process returning the process wouldn't dealloc it. If you are fulfilling a promise in another Thread, then the expectation will be that the allocator of the promise will use the promise to put on callbacks, and the thread to which the cloned promise was passed should eventually fulfill the promise (or, clone it again before dying).

So, I think it should work! But, wow, requires some thought to prove it. I still think there is an edge case lurking out there... but again... I have no proof.

Maybe it'd be good to reference this discussion in a comment.

[viperscape]

This is interesting and something to think about. I think with greater use a race condition might present itself; it's hard to predict such things though

[timcharper]

@viperscape I think what may be a better solution (to get your closed promise assurance) is to use an executor (pass lambda to a Future with an executor). And then, use the deallocation callback of a special reference for this unique data structure instance to signal fail the promise if it's not already closed.