Boost C++ Libraries: Ticket #8600: wait_for_any hangs, if called with multiple copies of shared_future referencing same task

owner, status changed

viboes — Tue, 21 May 2013 17:44:34 GMT

owner changed from Anthony Williams to viboes
status new → assigned

Thanks for catching this, even if I would not this to work.

I think the fix would be to document that the shared state of the N-futures must be different as a pre-condition.

I don't think the library must provide any check to avoid this usage.

Wed, 22 May 2013 07:24:08 GMT

That's fine with me, as long as there is a possibility to detect, if two shared_futures point to the same object. Currently there is no such function, so there is no possibility to remove the duplicates before calling wait_for_any.

viboes — Thu, 23 May 2013 21:59:26 GMT

Replying to Martin Apel <martin.apel@…>:

That's fine with me, as long as there is a possibility to detect, if two shared_futures point to the same object. Currently there is no such function, so there is no possibility to remove the duplicates before calling wait_for_any.

I understand your concern. I will see what can be done.

viboes — Fri, 24 May 2013 19:58:04 GMT

What would you expect from the following code

int main(int argc, char* argv[])
{
   boost::packaged_task<int> pt(calculate_the_answer_to_life_the_universe_and_everything);
   boost::future<int> fi1 = pt.get_future();
   boost::thread task(boost::move(pt)); // launch task on a thread
   boost::wait_for_any(fi1, fi1);
   std::cout << "Wait for any returned\n";
   return (0);
}

Mon, 27 May 2013 06:50:51 GMT

Interesting. I see that it's strange to explicitly pass two identical objects in there, but I would still expect it to wait correctly and not to silently hang infinitely. When called with iterators, this becomes more natural, because it's nothing special if a list contains the same item twice.

I would be perfectly happy to avoid this situation, if there only was a possibility to detect his. I have now found a workaround for my application, where I pass additional data and filter out futures based on this additional data. The best approach for me would be, if there was an operator== for shared_future objects, so I can compare, if they point to the same object or not. This would not incur any overhead and still make my use case possible.

viboes — Tue, 04 Jun 2013 06:13:38 GMT

I have requested some advice to the std-proposal forum and when_all, when_any should work when the futures share the same associated shared state. I will need to rethink the algorithm.