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
drpc: fix concurrent large message corruption in multiplexed streams
With stream multiplexing, multiple streams write concurrently to a shared
buffer. The stream's rawWriteLocked used to split large messages into
multiple frames (via SplitData) and call WriteFrame for each chunk. Each
WriteFrame acquires the shared mutex independently, so frames from
different streams can interleave in the buffer. The reader on the other
side doesn't handle interleaved frames from different streams mid-packet.
When it sees a frame from a different stream, it resets the partial
packet, silently corrupting data for messages larger than SplitSize.
The fix changes the StreamWriter interface from WriteFrame(Frame) to
WritePacket(Packet). The stream hands off the full message data in a
single call, and the writer serializes it atomically under one mutex
hold. rawWriteLocked no longer splits messages into frames, so there is
nothing to interleave.
Splitting may have been useful before multiplexing. The manageWriter
goroutine already batches all pending data from the shared buffer into a
single transport write, so splitting at the stream level adds no value.
If we ever need to limit per-write size, that belongs in the writer
implementation, not in the stream's rawWrite path.
0 commit comments