You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a potential race condition when using monitor_t in an inheritance tree upon deallocation.
If the monitored socket is created in the child class, the monitor socket will be closed only after the monitored socket, introducing a potential race condition, because the monitored socket may get reaped by the time the deallocation is still ongoing, possibly resulting in undefined behavior when accessing the _Tag member to verify whether the socket being monitored is still valid or not.
It is therefor 'a good idea' to deallocate the monitor socket prior to the monitored socket.
This, however, is not easy to achieve with the inheritance model.
To remedy the issue, I'd like to suggest composition, with the monitor_t instance being cleaned up prior to the monitored socket.
This, however, is not easily possible, because 'process_event' is only available in a protected context and requires overloading.
I therefor suggest splitting the function into two parts: get_event (public) would fetch the event and store it into a structure containing the zmq_event_t as well as the address. process_event(protected) would call get_event to fetch the event and process it as usual, maintaining the API.
This way, the raw instance of monitor_t can be used in composition without subclassing.
There is a potential race condition when using monitor_t in an inheritance tree upon deallocation.
If the monitored socket is created in the child class, the monitor socket will be closed only after the monitored socket, introducing a potential race condition, because the monitored socket may get reaped by the time the deallocation is still ongoing, possibly resulting in undefined behavior when accessing the _Tag member to verify whether the socket being monitored is still valid or not.
It is therefor 'a good idea' to deallocate the monitor socket prior to the monitored socket.
This, however, is not easy to achieve with the inheritance model.
To remedy the issue, I'd like to suggest composition, with the monitor_t instance being cleaned up prior to the monitored socket.
This, however, is not easily possible, because 'process_event' is only available in a protected context and requires overloading.
I therefor suggest splitting the function into two parts:
get_event
(public) would fetch the event and store it into a structure containing the zmq_event_t as well as the address.process_event
(protected) would call get_event to fetch the event and process it as usual, maintaining the API.This way, the raw instance of monitor_t can be used in composition without subclassing.
I am attaching a suggestion: suggestion.zip
The text was updated successfully, but these errors were encountered: