See value stored in head/tail of queue
Closed this issue · 5 comments
Not sure if this is an anti-pattern towards what you guys have implemented. But I'd like to know if there's any reason as to why there's no functions such as get_head, get_tail for the Bounded and Unbounded queues?
I have a use case where I do not want to push an item onto the queue if said item was the last thing to be added. Hence the question.
Thanks!
Not sure if this is an anti-pattern towards what you guys have implemented. But I'd like to know if there's any reason as to why there's no functions such as
get_head,get_tailfor theBoundedandUnboundedqueues?
It would be unsound to have these functions with the current implementation of concurrent-queue. If get_tail returned an &T, when a simultaneous pop operation would make it so that reference is invalidated. This would only work if get_tail took an &mut reference, where the borrow checker can assert that the current user is the only one who has access to the queue.
I would accept a PR adding methods to handle queue operations in an &mut way.
I have a use case where I do not want to push an item onto the queue if said item was the last thing to be added. Hence the question.
It might be worth it to de-duplicate the item at the point where it's popped, i.e. keep a copy of the item on hand and then ignore a pop() if it's equal to the last item. If your workload doesn't involve a lot of synchronization, a Mutex<VecDeque> would also be an option.
Appreciate your reply!
If get_tail returned an &T, when a simultaneous pop operation would make it so that reference is invalidated.
Oh, that actually makes a lot of sense, now that you said it.
I would accept a PR adding methods to handle queue operations in an &mut way.
I'd like to try that, will attempt to submit a draft PR for one of the queues! In this case we're talking about adding get_tail and get_head, each function receiving &mut self and returning the value in the queue, correct? Should it be a Result<T> or just the value T? (Maybe a result in case the queue is empty)
It might be worth it to de-duplicate the item at the point where it's popped, i.e. keep a copy of the item on hand and then ignore a pop() if it's equal to the last item.
Yep, that also makes sense. For now, I can live with duplicates, it was more a matter of premature optimization on my end. But if I can get the get_tail and get_head methods to work that would be ideal!
Personally, I think something like an iterator that returns a mutable reference to an element is preferable to this. (like FuturesUnorded::iter_mut)
Yep, agree this seems like a bit of an anti-pattern. Will close the PR linked to it.
On another note, something I'd like to see is a circular queue of fixed size. But perhaps this should be another issue.
I'll close this for now and I'll reopen if I ever come around implementing an iterator.