Fix race condition in javascript kernel message processing #7780
Conversation
Because the binary messages are now deserialized using the asynchronous FileReader API, we need to have some way to force the messages to still be processed in the order they are received. This patch implements a simple processing queue using promises.
|
This looks about as simple as I could have hoped. Thanks, @jasongrout! |
|
A test would be awesome, but this looks great to me. |
jasongrout
force-pushed
the
message-race
branch
from
18d3048 to
217dfd8
Compare
|
@minrk - I think this is ready for review. When I tried testing it using |
|
Can slimer test the binary websockets? |
|
In principle, it should be able to. Last time I tried running the tests on
slimer there were other failures, though.
|
|
@jasongrout this looks very similar to the solution you devised for the widget, thanks! +1 for 3.1 . |
|
When I wrote the binary websocket test, I was using slimer. I've since uninstalled it, and it's been a little while since I used it, but I can try running it when I get back tomorrow. |
msg count and msgspec v5 API changes
|
@jasongrout I made jasongrout#7 (if you don't want to add the PR+PR merge commit, you can cherry pick or rebase after merging), after which the tests pass. Your added tests pass fine, but the changes here and older msgspec changes caused the last segment of the test to fail. |
update js serialize test
|
@minrk: I merged your PR; thanks! |
|
@jasongrout thanks! |
Fix race condition in javascript kernel message processing
5 participants
Because the binary messages are now deserialized using the asynchronous FileReader API, we need to have some way to force the messages to still be processed in the order they are received. This patch implements a simple processing queue using promises.