docs(lp32): Elaborate README - #3044
Conversation
| }); | ||
|
|
||
| const encoder = new TextEncoder(); | ||
| await writer.next(encoder.encode('hello')); |
There was a problem hiding this comment.
Indeed, using the iterator protocol directly, we don’t suffer the parity mismatch of generators. This comes up in the draft exo-stream change as well.
|
|
||
| const reader = makeLp32Reader(byteStream, { | ||
| name: '<my-stream>', // optional, for error messages | ||
| maxMessageLength: 1024 * 1024, // optional, defaults to 1MB |
There was a problem hiding this comment.
What happens if the max is exceeded?
| // Producer | ||
| await writer.next(encoder.encode('message 1')); | ||
| await writer.next(encoder.encode('message 2')); | ||
| await writer.return(); |
There was a problem hiding this comment.
Are these awaits for flow control? I notice there is an initialCapacity and a maxMessageLength but no maxCapacity. So what does the flow control wait for?
There was a problem hiding this comment.
The awaits are for flow control. The reader must call next for the producer to advance. There’s a facility in @endo/stream for pre-acking so that these pipeline within pre-arranged bounds, but the default is that they’re synchronized.
There was a problem hiding this comment.
By "but the default is that they’re synchronized." do you mean there is effectively a zero-sized buffer, i.e., that this is a rendezvous protocol by default? This question should not delay merging, especially since this PR only documents the status quo. But I would like to discuss sometime. Low priority compared to everything else going on right now though.
There was a problem hiding this comment.
Yes, the default is effectively a zero-sized buffer.
292dc63 to
6f7547c
Compare
2 participants
This change documents the lp32 package. It also addresses some minor inconsistencies in the implementation. The byte order for native messages is not configurable.