In light of the discussion on the daq-app-fmwk Slack channel and this morning's Core Software WG meeting, we now support versions of send and receive functions which don't throw timeout exceptions. The reason for this is that there's overhead and mutex locking which goes on when we use exception throwing functions in multithreaded programs that can slow down things considerably. In the relevant headers of this package (e.g. Receiver.hpp and Sender.hpp) comments should be added emphasizing when timeout throwing vs. non-timeout throwing versions of send and receive functions should be used. The idea is that timeout throwing functions should only be used when a timeout is exceptional, as opposed to something common. The developer should also be made aware of the time overhead added by timeout exception throwing. Along with comments in the headers it may also be useful to add information about this in the iomanager documentation (https://dune-daq-sw.readthedocs.io/en/latest/packages/iomanager/)
In light of the discussion on the daq-app-fmwk Slack channel and this morning's Core Software WG meeting, we now support versions of send and receive functions which don't throw timeout exceptions. The reason for this is that there's overhead and mutex locking which goes on when we use exception throwing functions in multithreaded programs that can slow down things considerably. In the relevant headers of this package (e.g.
Receiver.hppandSender.hpp) comments should be added emphasizing when timeout throwing vs. non-timeout throwing versions of send and receive functions should be used. The idea is that timeout throwing functions should only be used when a timeout is exceptional, as opposed to something common. The developer should also be made aware of the time overhead added by timeout exception throwing. Along with comments in the headers it may also be useful to add information about this in the iomanager documentation (https://dune-daq-sw.readthedocs.io/en/latest/packages/iomanager/)