Re: [Boost-bugs] [Boost C++ Libraries] #7669: thread_group::join_all() should catch resource_deadlock_would_occur

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #7669: thread_group::join_all() should catch resource_deadlock_would_occur
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-11-10 19:19:14

#7669: thread_group::join_all() should catch resource_deadlock_would_occur
------------------------------------+---------------------------------------
  Reporter:  boost.lists@…          |       Owner:  anthonyw           
      Type:  Bugs                   |      Status:  new                
 Milestone:  To Be Determined       |   Component:  thread             
   Version:  Boost 1.52.0           |    Severity:  Problem            
Resolution:                         |    Keywords:  thread;thread_group
------------------------------------+---------------------------------------

Comment (by Igor R. <boost.lists@…>):

 Replying to [comment:3 viboes]:

 First of all, the question is whether we want to improve thread_group and
 make it more usable - or not. If you really intend to deprecate it, then
 perhaps changing the formal pre-condition is enough. On the other hand, if
 the intent is to improve the usability, I'am afraid none of the 2 options
 would really help.



 > You are right, the user can not check this pre-condition as it has no
 access to the threads in the group other than duplicating. But calling to
 join_all and joining all but one of the threads don't respect either the
 post-conditions.

 Right, the post-condition should be updated, if you decide to handle
 this_thread case. But please note that thread::join() post-condition is
 also incorrect with regard to this issue. IIUC, this story began when
 thread::join() just deadlocked if it was this_thread, and thread &
 thread_group behaved consistently at this point; then the deadlock issue
 was solved by throwing resource_deadlock_would_occur exception, but
 neither formal post-condition of thread::join() nor thread_group behavior
 were updated.


 > I don't think it is a good design to to request to join on itself.

 Usually it's not a deliberate decision to join on itself, but design
 constraints, when trying to avoid this situation might unnecessarily
 complicate design. But "bad design" argument is even more applicable to
 thread::join() itself - nevertheless its behavior is reasonable and
 doesn't produce UB.


 > - the implementation check always if the this_thread is in the thread
 group and throw a specific exception

 What should the user do at this point? IIUC, it's impossible to recover
 from this situation (as opposed to thread::join() case!).

 > - the library provides a function that states if this_thread is in the
 thread group, so that the user that is in a context that the current
 thread could be one of the group could check it. The join_all function has
 the Require clause described above.

 Actually, this's equivalent to the above option, i.e the user will get
 information but won't be able to recover.

 P.S. please note that this ticket doesn't differ much from #7668.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/7669#comment:4>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.