To my understanding, the SerialConnection has a single mutex to lock the port attribute, this means that if a SerialConnection is shared between threads using Arc (like in the mavlink-dump binary) it won't be posible to perform a recv call in one thread and a send call in another thread at the same time. If no messages are received it will never be able to send (mutex will be locked until recv ends).
SerialPorts can send and receive at the same time, but the crate used doesn't split the tx and rx channels, I guess this is why a single Port and mutex is being used.
How can a workaround be implemented?
Would it be posible to have an auxiliary mutex to split reading and writing locks? Methods performing read operations would lock an specific mutex and methods performing write operations would lock the other mutex. It's not elegant but the port is hidden inside the structure. Would this make any sense?
Hi,
To my understanding, the SerialConnection has a single mutex to lock the port attribute, this means that if a SerialConnection is shared between threads using Arc (like in the mavlink-dump binary) it won't be posible to perform a recv call in one thread and a send call in another thread at the same time. If no messages are received it will never be able to send (mutex will be locked until recv ends).
SerialPorts can send and receive at the same time, but the crate used doesn't split the tx and rx channels, I guess this is why a single Port and mutex is being used.
How can a workaround be implemented?
Would it be posible to have an auxiliary mutex to split reading and writing locks? Methods performing read operations would lock an specific mutex and methods performing write operations would lock the other mutex. It's not elegant but the port is hidden inside the structure. Would this make any sense?