Queue does not currently have discard semantics implemented, so discard() does nothing.
Keep in mind that f.discard() is just a request, and f.hasDiscard() tells you if the request was made. It's up to the promise owner to decide if discards are supported, and so after a discard is requested the future may still transition to a READY or FAILED state. If the callee is able to stop the work, then promise.discard() is called and the future transitions to the DISCARDED state. So, while the caller can request a discard, it still needs to be prepared to handle any transition afterwards. If you want to add discard semantics, inside process::Queue we would need to implement an onDiscard handler for the futures we return from the "waiters" promises. This handler will run when the caller requests a discard. The logic in this handler would be to discard the corresponding promise and remove it from the deque. Of course, the handler needs to handle the fact that the promise was set before we were able to get to the discard handler, in which case we do nothing. Does that help? On Tue, Dec 15, 2015 at 8:42 PM, James Peach <[email protected]> wrote: > > > On Dec 14, 2015, at 3:51 PM, James Peach <[email protected]> wrote: > > > > Hi all, > > > > I wrote some test code that was trying to drain a process::Queue. This > ended up losing values from the queue, as demonstrated by: > > > > TEST(QueueTest, Discard) > > { > > Queue<int> q; > > > > Future<int> get = q.get(); > > EXPECT_FALSE(get.isReady()); > > > > get.discard(); > > EXPECT_TRUE(get.hasDiscard()); > > Thinking about this more; simply discarding the future races with another > thread putting a value into the Queue. So maybe the use cases for using > Queue safely are more restrictive than I had imagined. > > J
