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
The issue is initially discussed on Discord. This issue is for future tracking and notes. This may be a bug or it may not.
The issue can be reproduced by removing async_helpers::sleep in examples/stock_server.rs. Then, start the examples and the client will wait for data. Only the first 128 frames are received on the client.
However, if we change that to wait for even 1ns, the client will receive data properly. After an initial search, I found that Poll::Pending is somehow polled from the ready_queue and hence it is being propagated.
The text was updated successfully, but these errors were encountered:
poyea
changed the title
recv wait indefinitely in the stock example that uses a SUB socketrecv may wait indefinitely in a SUB socket
Jun 23, 2022
Hi. Not sure that your description is actually related to the problem. async_helpers::sleep is needed just to simulate some kind of logical delay in producing messages. Without it PUB socket will simply spam as many messages as it can (and it can do a lot..). According to ZMQ spec PUB socket never blocks and simply discards messages that it cannot deliver. So in result it would simply throw away messages that don't fit in network buffer
The issue is initially discussed on Discord. This issue is for future tracking and notes. This may be a bug or it may not.
The issue can be reproduced by removing
async_helpers::sleep
inexamples/stock_server.rs
. Then, start the examples and the client will wait for data. Only the first 128 frames are received on the client.However, if we change that to wait for even 1ns, the client will receive data properly. After an initial search, I found that
Poll::Pending
is somehow polled from theready_queue
and hence it is being propagated.The text was updated successfully, but these errors were encountered: