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
I ran into a strange issue where a test of mine was hanging. Interestingly, changing from an instance of Async<serialport::TTYPort> to Async<mio_serial::SerialStream> seems to solve the problem. At first, I thought that was significant, but now I think it may just be coincidental.
While trying to create a minimal reproduction, it looks like swapping the order of smol::spawn calls influences the outcome. That fact, combined with knowledge that the ReadHalf and WriteHalf types returned by smol::io::split wrap instances of Arc<Mutex<T>>, makes me strongly suspect this is a deadlock of some kind. That's reinforced by the fact that I'm seeing slightly different behavior between my minimal example and my real code. Moreover, I've now seen variation in the behavior from day to day. Finally, I should note that the problem goes away completely if I spawn two instances of smol::io::copy. However, as mentioned in smol-rs/smol#270, one of these streams can't be implemented with smol::io::copy.
Here is the reproduction code. It's specific to my system, because it communicates with my serial device. But it could be easily adapted to some other device.
When I run this code, the blocking_serialport and async_mio_serial tests pass, but the async_serialport test hangs. However, if I move the spawn of smol::io::copy to the indicated position, all tests pass.
Hi,
I ran into a strange issue where a test of mine was hanging. Interestingly, changing from an instance of
Async<serialport::TTYPort>
toAsync<mio_serial::SerialStream>
seems to solve the problem. At first, I thought that was significant, but now I think it may just be coincidental.While trying to create a minimal reproduction, it looks like swapping the order of
smol::spawn
calls influences the outcome. That fact, combined with knowledge that theReadHalf
andWriteHalf
types returned bysmol::io::split
wrap instances ofArc<Mutex<T>>
, makes me strongly suspect this is a deadlock of some kind. That's reinforced by the fact that I'm seeing slightly different behavior between my minimal example and my real code. Moreover, I've now seen variation in the behavior from day to day. Finally, I should note that the problem goes away completely if I spawn two instances ofsmol::io::copy
. However, as mentioned in smol-rs/smol#270, one of these streams can't be implemented withsmol::io::copy
.Here is the reproduction code. It's specific to my system, because it communicates with my serial device. But it could be easily adapted to some other device.
When I run this code, the
blocking_serialport
andasync_mio_serial
tests pass, but theasync_serialport
test hangs. However, if I move thespawn
ofsmol::io::copy
to the indicated position, all tests pass.The text was updated successfully, but these errors were encountered: