2 bugs were present (with smaller statistical chances also relevant for USB devices, but leaved it out for now)
dispatcherDeviceFdDown wasn't set back to 0 between destroying and creating a new link
XLinkFD used to tie the underlying physical link and the scheduler is thought to be unique - but with TCP its actually a reusable FD number, where new link can get the same value soon after the previous link closes down. This caused __rpc_main issues as read/write events were routed to wrong physical link.
Resolved the unique XLinkFD issue by adding a map which keeps track of open physical links and assigns them an unique incrementing number instead.
USB (AFAIK) uses a pointer to underlying structure (eg. libusb handle), which in theory can be reused as well if a new handle is allocated at same address. As we haven't seen this issue yet, I left it for now to reduce changes associated with the PR.
2 bugs were present (with smaller statistical chances also relevant for USB devices, but leaved it out for now)
dispatcherDeviceFdDownwasn't set back to 0 between destroying and creating a new linkXLinkFDused to tie the underlying physical link and the scheduler is thought to be unique - but with TCP its actually a reusable FD number, where new link can get the same value soon after the previous link closes down. This caused__rpc_mainissues as read/write events were routed to wrong physical link.Resolved the unique XLinkFD issue by adding a map which keeps track of open physical links and assigns them an unique incrementing number instead.
USB (AFAIK) uses a pointer to underlying structure (eg. libusb handle), which in theory can be reused as well if a new handle is allocated at same address. As we haven't seen this issue yet, I left it for now to reduce changes associated with the PR.