Handle CommManager messages in order#7839
Conversation
|
My initial impression is that I prefer this over #7838 for two reasons:
|
|
I'm a bit torn. I probably prefer this for 3.x due to its relative simplicity, but in the long run, I think the synchronization should probably be done at the lower level, forcing ordering at the channel or socket level, rather than per message type. Now that we understand working with promises and 🐴 better, I think for 4.0 we should take a step back and rework the callbacks/event handling of messages to be consistent across the board, rather than the inconsistent mixture of approaches we have right now. Almost all of the problems we have with respect to these things are specific to widgets, and we have to be realistic about what widgets are going to be in 3.x. |
|
I like #7838 better. It allows any message handler to be synchronous, not just comms. It's simpler conceptually. |
A problem can happen when two messages come in for different comms, where the second depends on the first (for example, the first might be a message setting the state of a widget, and the second triggering a view creation for the widget). Since comm message queues are independent of each other, the second message could be executed before the first message. Thanks to @dmadeka for reporting an error that led to discovering this issue.
44c0417 to
35350ee
Compare
|
closing in favor of #7838 |
A problem can happen when two messages come in for different
comms, where the second depends on the first (for example, the
first might be a message setting the state of a widget, and the
second triggering a view creation for the widget). Since comm
message queues are independent of each other, the second message
could be executed before the first message.