Issues with boost executor_work_guard
Hello all, We are facing some issues with boost::asio::executor_work_guard. We are spawning some threads which are bound to a boost::asio::io_context and proteced by a boost::asio::executor_work_guard so that they do not exit even if there is no work to be done. However, despite the work_guard still being valid, we see that the threads exit because boost::asio::detail::scheduler::outstanding_work reaches 0. All operations added to the queue are posted asynchronously. The boost version in use is 1.75 (also tested with 1.78 and the behaviour is the same). Could you help us on the following topics so that we can understand what the root cause may be? 1 - We created an implementation to track the number of elements on boost::asio::detail::op_queue, is this implementation valid? uint32_t size() { auto tmp_op = front_; uint32_t size{0}; while (tmp_op != 0) { ++size; tmp_op = op_queue_access::next(tmp_op); } return size; } 2 - Assuming the approach above is correct, we are trying to compare the values of outstanding_work with the returned value of op_queue.size(). However, these values do not seem to correlate, is this to be expected? 3 - Was this issue observed by someone else? If so what were the root causes? Thanks! Kind Regards, João Silva The information in this communication may contain confidential or legally privileged information. It is intended solely for the use of the individual or entity it addresses and others authorized to receive it. If you are not an intended recipient, you are hereby notified that any disclosure, copying, distribution or action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication by error, please notify us immediately by responding to this e-mail and then delete it from your system. Critical TechWorks is not liable for the proper and complete transmission of the information in this communication nor for any delay in its receipt This e-mail is environmentally friendly, just like Critical TechWorks, which lives in a paper-free atmosphere. Therefore, please consider the environment before printing it!
On Mon, Apr 7, 2025 at 7:07 AM João Fernando Silva via Boost-users < boost-users@lists.boost.org> wrote:
...despite the work_guard still being valid, we see that the threads exit because boost::asio::detail::scheduler::outstanding_work reaches 0.
If you could create a small, self-contained program which demonstrates this behavior it would be very helpful for diagnosing the problem. Thanks
Hi Vinnie, Unfortunately we are unable to do so. We have only seen this happen with a specific application that interacts with our code (which is proprietary) and could not replicate it elsewhere. You can take a look at our code here https://github.com/COVESA/vsomeip. The relevant lines in this case are these https://github.com/COVESA/vsomeip/blob/master/implementation/runtime/src/app... https://github.com/COVESA/vsomeip/blob/master/implementation/runtime/src/app... https://github.com/COVESA/vsomeip/blob/master/implementation/runtime/src/app... Thanks ________________________________ From: Vinnie Falco <vinnie.falco@gmail.com> Sent: Monday, April 7, 2025 3:51 PM To: boost-users@lists.boost.org <boost-users@lists.boost.org> Cc: João Fernando Silva <joao.fernando.silva@partner.criticaltechworks.com> Subject: Re: [Boost-users] Issues with boost executor_work_guard Notice: This e-mail has originated from an external email service, so do not click on any links, nor open any attachments unless you know who the sender is and are sure the content is secure. On Mon, Apr 7, 2025 at 7:07 AM João Fernando Silva via Boost-users <boost-users@lists.boost.org<mailto:boost-users@lists.boost.org>> wrote: ...despite the work_guard still being valid, we see that the threads exit because boost::asio::detail::scheduler::outstanding_work reaches 0. If you could create a small, self-contained program which demonstrates this behavior it would be very helpful for diagnosing the problem. Thanks The information in this communication may contain confidential or legally privileged information. It is intended solely for the use of the individual or entity it addresses and others authorized to receive it. If you are not an intended recipient, you are hereby notified that any disclosure, copying, distribution or action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication by error, please notify us immediately by responding to this e-mail and then delete it from your system. Critical TechWorks is not liable for the proper and complete transmission of the information in this communication nor for any delay in its receipt This e-mail is environmentally friendly, just like Critical TechWorks, which lives in a paper-free atmosphere. Therefore, please consider the environment before printing it!
Is one of your completion handlers throwing an exception? On Mon, 7 Apr 2025 at 18:04, João Fernando Silva via Boost-users < boost-users@lists.boost.org> wrote:
Hi Vinnie,
Unfortunately we are unable to do so. We have only seen this happen with a specific application that interacts with our code (which is proprietary) and could not replicate it elsewhere.
You can take a look at our code here https://github.com/COVESA/vsomeip. The relevant lines in this case are these
https://github.com/COVESA/vsomeip/blob/master/implementation/runtime/src/app...
https://github.com/COVESA/vsomeip/blob/master/implementation/runtime/src/app...
https://github.com/COVESA/vsomeip/blob/master/implementation/runtime/src/app...
Thanks ------------------------------ *From:* Vinnie Falco <vinnie.falco@gmail.com> *Sent:* Monday, April 7, 2025 3:51 PM *To:* boost-users@lists.boost.org <boost-users@lists.boost.org> *Cc:* João Fernando Silva < joao.fernando.silva@partner.criticaltechworks.com> *Subject:* Re: [Boost-users] Issues with boost executor_work_guard
*Notice:* This e-mail has originated from an external email service, so do not click on any links, nor open any attachments unless you know who the sender is and are sure the content is secure.
On Mon, Apr 7, 2025 at 7:07 AM João Fernando Silva via Boost-users < boost-users@lists.boost.org> wrote:
...despite the work_guard still being valid, we see that the threads exit because boost::asio::detail::scheduler::outstanding_work reaches 0.
If you could create a small, self-contained program which demonstrates this behavior it would be very helpful for diagnosing the problem.
Thanks
The information in this communication may contain confidential or legally privileged information. It is intended solely for the use of the individual or entity it addresses and others authorized to receive it. If you are not an intended recipient, you are hereby notified that any disclosure, copying, distribution or action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication by error, please notify us immediately by responding to this e-mail and then delete it from your system. Critical TechWorks is not liable for the proper and complete transmission of the information in this communication nor for any delay in its receipt
*This e-mail is environmentally friendly, just like Critical TechWorks, which lives in a paper-free atmosphere. Therefore, please consider the environment before printing it! * _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
No, no exceptions are thrown ________________________________ From: Boost-users <boost-users-bounces@lists.boost.org> on behalf of Richard Hodges via Boost-users <boost-users@lists.boost.org> Sent: Monday, April 7, 2025 6:03 PM To: boost-users@lists.boost.org <boost-users@lists.boost.org> Cc: Richard Hodges <hodges.r@gmail.com> Subject: Re: [Boost-users] Issues with boost executor_work_guard Notice: This e-mail has originated from an external email service, so do not click on any links, nor open any attachments unless you know who the sender is and are sure the content is secure. Is one of your completion handlers throwing an exception? On Mon, 7 Apr 2025 at 18:04, João Fernando Silva via Boost-users <boost-users@lists.boost.org<mailto:boost-users@lists.boost.org>> wrote: Hi Vinnie, Unfortunately we are unable to do so. We have only seen this happen with a specific application that interacts with our code (which is proprietary) and could not replicate it elsewhere. You can take a look at our code here https://github.com/COVESA/vsomeip. The relevant lines in this case are these https://github.com/COVESA/vsomeip/blob/master/implementation/runtime/src/app... https://github.com/COVESA/vsomeip/blob/master/implementation/runtime/src/app... https://github.com/COVESA/vsomeip/blob/master/implementation/runtime/src/app... Thanks ________________________________ From: Vinnie Falco <vinnie.falco@gmail.com<mailto:vinnie.falco@gmail.com>> Sent: Monday, April 7, 2025 3:51 PM To: boost-users@lists.boost.org<mailto:boost-users@lists.boost.org> <boost-users@lists.boost.org<mailto:boost-users@lists.boost.org>> Cc: João Fernando Silva <joao.fernando.silva@partner.criticaltechworks.com<mailto:joao.fernando.silva@partner.criticaltechworks.com>> Subject: Re: [Boost-users] Issues with boost executor_work_guard Notice: This e-mail has originated from an external email service, so do not click on any links, nor open any attachments unless you know who the sender is and are sure the content is secure. On Mon, Apr 7, 2025 at 7:07 AM João Fernando Silva via Boost-users <boost-users@lists.boost.org<mailto:boost-users@lists.boost.org>> wrote: ...despite the work_guard still being valid, we see that the threads exit because boost::asio::detail::scheduler::outstanding_work reaches 0. If you could create a small, self-contained program which demonstrates this behavior it would be very helpful for diagnosing the problem. Thanks The information in this communication may contain confidential or legally privileged information. It is intended solely for the use of the individual or entity it addresses and others authorized to receive it. If you are not an intended recipient, you are hereby notified that any disclosure, copying, distribution or action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication by error, please notify us immediately by responding to this e-mail and then delete it from your system. Critical TechWorks is not liable for the proper and complete transmission of the information in this communication nor for any delay in its receipt This e-mail is environmentally friendly, just like Critical TechWorks, which lives in a paper-free atmosphere. Therefore, please consider the environment before printing it! _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org<mailto:Boost-users@lists.boost.org> https://lists.boost.org/mailman/listinfo.cgi/boost-users The information in this communication may contain confidential or legally privileged information. It is intended solely for the use of the individual or entity it addresses and others authorized to receive it. If you are not an intended recipient, you are hereby notified that any disclosure, copying, distribution or action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication by error, please notify us immediately by responding to this e-mail and then delete it from your system. Critical TechWorks is not liable for the proper and complete transmission of the information in this communication nor for any delay in its receipt This e-mail is environmentally friendly, just like Critical TechWorks, which lives in a paper-free atmosphere. Therefore, please consider the environment before printing it!
Hello all, A follow up on this as we are still suffering from the issue. We continued with our investigation and found no weird behaviours happening within boost. The increments/decrements to the queue all make sense, and also boost::asio::detail::scheduler::outstanding_work does not have weird changes in values (thus we excluded the hipothesis of it being a memory corruption). As I said previously we check that the boost::asio::executor_work_guard is still valid and that the io_context does not return any exceptions or error code. 1. Could a fake job being posted to the queue cause this issue? Has anyone seen this happen? 1. Another question, could thread niceness have an impact on the outstanding_work reaching zero? We so far have only seen this behaviour occuring on an application with a low niceness value (-10) ________________________________ From: João Fernando Silva <joao.fernando.silva@partner.criticaltechworks.com> Sent: Tuesday, April 8, 2025 9:15 AM To: boost-users@lists.boost.org <boost-users@lists.boost.org> Cc: Richard Hodges <hodges.r@gmail.com> Subject: Re: [Boost-users] Issues with boost executor_work_guard No, no exceptions are thrown ________________________________ From: Boost-users <boost-users-bounces@lists.boost.org> on behalf of Richard Hodges via Boost-users <boost-users@lists.boost.org> Sent: Monday, April 7, 2025 6:03 PM To: boost-users@lists.boost.org <boost-users@lists.boost.org> Cc: Richard Hodges <hodges.r@gmail.com> Subject: Re: [Boost-users] Issues with boost executor_work_guard Notice: This e-mail has originated from an external email service, so do not click on any links, nor open any attachments unless you know who the sender is and are sure the content is secure. Is one of your completion handlers throwing an exception? On Mon, 7 Apr 2025 at 18:04, João Fernando Silva via Boost-users <boost-users@lists.boost.org<mailto:boost-users@lists.boost.org>> wrote: Hi Vinnie, Unfortunately we are unable to do so. We have only seen this happen with a specific application that interacts with our code (which is proprietary) and could not replicate it elsewhere. You can take a look at our code here https://github.com/COVESA/vsomeip. The relevant lines in this case are these https://github.com/COVESA/vsomeip/blob/master/implementation/runtime/src/app... https://github.com/COVESA/vsomeip/blob/master/implementation/runtime/src/app... https://github.com/COVESA/vsomeip/blob/master/implementation/runtime/src/app... Thanks ________________________________ From: Vinnie Falco <vinnie.falco@gmail.com<mailto:vinnie.falco@gmail.com>> Sent: Monday, April 7, 2025 3:51 PM To: boost-users@lists.boost.org<mailto:boost-users@lists.boost.org> <boost-users@lists.boost.org<mailto:boost-users@lists.boost.org>> Cc: João Fernando Silva <joao.fernando.silva@partner.criticaltechworks.com<mailto:joao.fernando.silva@partner.criticaltechworks.com>> Subject: Re: [Boost-users] Issues with boost executor_work_guard Notice: This e-mail has originated from an external email service, so do not click on any links, nor open any attachments unless you know who the sender is and are sure the content is secure. On Mon, Apr 7, 2025 at 7:07 AM João Fernando Silva via Boost-users <boost-users@lists.boost.org<mailto:boost-users@lists.boost.org>> wrote: ...despite the work_guard still being valid, we see that the threads exit because boost::asio::detail::scheduler::outstanding_work reaches 0. If you could create a small, self-contained program which demonstrates this behavior it would be very helpful for diagnosing the problem. Thanks The information in this communication may contain confidential or legally privileged information. It is intended solely for the use of the individual or entity it addresses and others authorized to receive it. If you are not an intended recipient, you are hereby notified that any disclosure, copying, distribution or action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication by error, please notify us immediately by responding to this e-mail and then delete it from your system. Critical TechWorks is not liable for the proper and complete transmission of the information in this communication nor for any delay in its receipt This e-mail is environmentally friendly, just like Critical TechWorks, which lives in a paper-free atmosphere. Therefore, please consider the environment before printing it! _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org<mailto:Boost-users@lists.boost.org> https://lists.boost.org/mailman/listinfo.cgi/boost-users The information in this communication may contain confidential or legally privileged information. It is intended solely for the use of the individual or entity it addresses and others authorized to receive it. If you are not an intended recipient, you are hereby notified that any disclosure, copying, distribution or action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication by error, please notify us immediately by responding to this e-mail and then delete it from your system. Critical TechWorks is not liable for the proper and complete transmission of the information in this communication nor for any delay in its receipt This e-mail is environmentally friendly, just like Critical TechWorks, which lives in a paper-free atmosphere. Therefore, please consider the environment before printing it!
participants (3)
-
João Fernando Silva -
Richard Hodges -
Vinnie Falco