The byte pump gates every wire byte with no awareness of parser state, so a
base64 payload inside an APC or DCS string is paced at the emulated rate. At
2400 bps a 200 KB payload takes about 11 minutes with nothing on screen, which
reads as a hang.
Affected today: APC SyncTERM:C;S file store, the DrawPPMBlob,
DrawJXLBlob, LoadPPMBlob, LoadJXLBlob and LoadPBMBlob verbs, sixel, and
DCS font definitions.
Repro: BPS Rate 2400, host sends APC SyncTERM:C;S;t.wav;<200KB base64> ST.
The same at BPS Rate 0 completes immediately.
Two carve-outs already exist: parse_rip() runs over a whole wire chunk in
recv_bytes() ahead of the gate, and ZMODEM detection hands off to
zmodem_download(). Bulk APC and DCS payloads get neither.
A real 2400 bps modem would also have taken 11 minutes, so this may be
intended. Asking whether the RIP and ZMODEM carve-outs are meant to extend to
out-of-band payloads that display nothing while they stream.
Anonymous
This is intentional. RIP and ZModem aren't so much carve-outs as things that were too hard to pace when pacing was added. It's likely they will be paced in a future release.