When a subreceiver is dropped, MultiReceiver::drain is called to process any outstanding messages. This will ensure that any inflight subsenders are received and noted as "receive failed" in the corresponding subsender state machines.
However, MultiReceiver::drain calls IpcReceiver::try_receive when the multireceiver is not part of a MultiReceiverSet, but calls IpcReceiverSet::select when the multireceiver is part of a MultiReceiverSet. This will block and cause a deadlock.
The most obvious situation in which this can occur is when a subreceiver associated with the router (because a peer subreceiver was added to the router) is dropped. A test should be added for this case.
Another situation is where a SubReceiverSet is dropped and this causes all the subreceivers in the set to be dropped. However, this is unlikely to cause an issue with the router since the router's SubReceiverSet isn't dropped until the router is shutting down. (Note the SubReceiverSet is an internal and is only driven via the router.)
When a subreceiver is dropped,
MultiReceiver::drainis called to process any outstanding messages. This will ensure that any inflight subsenders are received and noted as "receive failed" in the corresponding subsender state machines.However,
MultiReceiver::draincallsIpcReceiver::try_receivewhen the multireceiver is not part of aMultiReceiverSet, but callsIpcReceiverSet::selectwhen the multireceiver is part of aMultiReceiverSet. This will block and cause a deadlock.The most obvious situation in which this can occur is when a subreceiver associated with the router (because a peer subreceiver was added to the router) is dropped. A test should be added for this case.
Another situation is where a
SubReceiverSetis dropped and this causes all the subreceivers in the set to be dropped. However, this is unlikely to cause an issue with the router since the router'sSubReceiverSetisn't dropped until the router is shutting down. (Note theSubReceiverSetis an internal and is only driven via the router.)