Closed gsegatti closed 1 year ago
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 theBounded
andUnbounded
queues?
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!
@notgull I've opened a draft PR #41 so you and the maintainers can give some early feedback!
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.
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 theBounded
andUnbounded
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!