[thread] scoped_thread' move assignment
Hi, I find myself in a strong disagreement with how scoped_thread's move assignment is defined. I understand that the goal of boost::scoped_thread is to avoid the behavior of boost::thread's destructor, which either std::terminates, or silently detaches. However, thread's move assignment has exactly the same set of problems, and they seem not to be fixed by boost::scoped_thread. Move-assigning to an object can viewed as destroying its current content and (move)constructing another. I would intuitively expect the same CallableThread()(t_)to be called. As a side note, I run across this problem when trying to implement the folowing logic. I have a running thread. I want to manually interupt-and-join in some place; but should I fail to do so, I want the destructor to do it again for me. I found that impossible to express with boost::scoped_thread. (Did I miss smething?). I expected that the move assignment would do the trick, but, lo, it does not. Regards, &rzej
Le 11/04/2016 13:13, Andrzej Krzemienski a écrit :
Hi, I find myself in a strong disagreement with how scoped_thread's move assignment is defined.
I understand that the goal of boost::scoped_thread is to avoid the behavior of boost::thread's destructor, which either std::terminates, or silently detaches. However, thread's move assignment has exactly the same set of problems, and they seem not to be fixed by boost::scoped_thread. Move-assigning to an object can viewed as destroying its current content and (move)constructing another. I would intuitively expect the same CallableThread()(t_)to be called. This is a bug, the callable should be called on the target thread before doing the move :( As a side note, I run across this problem when trying to implement the folowing logic. I have a running thread. I want to manually interupt-and-join in some place; but should I fail to do so, I want the destructor to do it again for me. I found that impossible to express with boost::scoped_thread. (Did I miss smething?). I expected that the move assignment would do the trick, but, lo, it does not.
Could you show me the code that you used to do that? I suspect that you need a functor object that do the interrupt and join logic. Vicente
Regards, &rzej
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
2016-04-17 21:49 GMT+02:00 Vicente J. Botet Escriba < vicente.botet@wanadoo.fr>:
Le 11/04/2016 13:13, Andrzej Krzemienski a écrit :
Hi, I find myself in a strong disagreement with how scoped_thread's move assignment is defined.
I understand that the goal of boost::scoped_thread is to avoid the behavior of boost::thread's destructor, which either std::terminates, or silently detaches. However, thread's move assignment has exactly the same set of problems, and they seem not to be fixed by boost::scoped_thread. Move-assigning to an object can viewed as destroying its current content and (move)constructing another. I would intuitively expect the same CallableThread()(t_)to be called.
This is a bug, the callable should be called on the target thread before doing the move :(
As a side note, I run across this problem when trying to implement the folowing logic. I have a running thread. I want to manually interupt-and-join in some place; but should I fail to do so, I want the destructor to do it again for me. I found that impossible to express with boost::scoped_thread. (Did I miss smething?). I expected that the move assignment would do the trick, but, lo, it does not.
Could you show me the code that you used to do that? I suspect that you need a functor object that do the interrupt and join logic.
Ok, some more background. First, I encountered the problem not at the point of writing the program but at the point of studying the documentation to determine if scoped_thread will do. This is what I found: http://www.boost.org/doc/libs/1_60_0/doc/html/thread/ScopedThreads.html#thre... After running some tests later, I see that the move assignment does in fact call the provided action, as I expected, and as you described. So, the bug is not in the implementation, but in documentation. Now that I know that move assignment works in the intuitive way, my use case is quite trivial to express: ``` void usage() { boost::scoped_thread<InterruptIf> th; th = boost::scoped_thread<InterruptIf>{loop}; } ``` I am using my own functor. I am hesitant to use interrupt_and_join_if_joinable http://www.boost.org/doc/libs/1_60_0/doc/html/thread/ScopedThreads.html#thre... because according to documentation it will call interrupt also on a non-joinable thread, and I am not sure what are the implications (in terms of program correctness and in terms of performance). Regards, &rzej
participants (2)
-
Andrzej Krzemienski -
Vicente J. Botet Escriba