Commit 01357bf
committed
async/client: don't spawn per incoming frame
ClientReader::handle_msg spawns a new task per frame. For a
server-streaming RPC, the final DATA frame and the subsequent
FLAG_REMOTE_CLOSED frame then race: if the close-frame task grabs
the req_map lock first, it removes the stream from the map, and
the preceding data-frame task finds nothing and silently drops
the payload. The stream consumer sees Ok(None) (EOF) without
ever observing the payload the server sent.
The connection read loop already awaits handle_msg per frame, so
processing inline preserves per-stream wire order. It also gives
the per-stream mpsc natural back-pressure in place of the
unbounded per-frame spawning.
handle_err gets the same treatment for consistency.
Also update example/async-stream-client.rs so the existing
echo_default_value example exercises the race: wrap it in a
1000-iteration loop and flip the client runtime to multi_thread.
On a single-threaded runtime the tokio scheduler masks the race
because spawned tasks run in submission order. Without the fix,
the modified example fails on any multi-core runner; with the
fix, it passes.
Signed-off-by: Shiv Bhosale <shvbsle@amazon.com>1 parent f31f592 commit 01357bf
1 file changed
Lines changed: 17 additions & 16 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
313 | 313 | | |
314 | 314 | | |
315 | 315 | | |
| 316 | + | |
316 | 317 | | |
317 | | - | |
318 | | - | |
319 | | - | |
320 | | - | |
321 | | - | |
322 | | - | |
323 | | - | |
324 | | - | |
| 318 | + | |
| 319 | + | |
| 320 | + | |
| 321 | + | |
| 322 | + | |
| 323 | + | |
325 | 324 | | |
326 | 325 | | |
327 | 326 | | |
| 327 | + | |
| 328 | + | |
| 329 | + | |
| 330 | + | |
328 | 331 | | |
329 | | - | |
330 | | - | |
331 | | - | |
332 | | - | |
333 | | - | |
334 | | - | |
335 | | - | |
336 | | - | |
| 332 | + | |
| 333 | + | |
| 334 | + | |
| 335 | + | |
| 336 | + | |
| 337 | + | |
337 | 338 | | |
338 | 339 | | |
0 commit comments