Out of curiosity, I wrapped David's code in a loop and tried to write 509 bytes in each iteration. From the output, it looks like CS doesn't implement pipes using a fixed-size buffer. I'm also not sure how many different buffers there are. I think this has something to do with George's question.
ITERATION 0 avail: 16777216 space available? #t pipe content length: 0 rx buffer overflow. pipe content length: 15, written 15, expected 509 ITERATION 1 avail: 16777201 space available? #t pipe content length: 15 rx buffer overflow. pipe content length: 31, written 16, expected 509 ITERATION 2 avail: 16777185 space available? #t pipe content length: 31 rx buffer overflow. pipe content length: 63, written 32, expected 509 ITERATION 3 avail: 16777153 space available? #t pipe content length: 63 rx buffer overflow. pipe content length: 127, written 64, expected 509 ITERATION 4 avail: 16777089 space available? #t pipe content length: 127 rx buffer overflow. pipe content length: 255, written 128, expected 509 done On Wed, Jun 16, 2021 at 4:34 PM George Neuner <[email protected]> wrote: > > > On 6/16/2021 3:45 PM, Matthew Flatt wrote: > > At Wed, 16 Jun 2021 14:25:40 -0400, George Neuner wrote: > > > It looks like the problem > > > is that "flush" is not defined ... > > > > Yes, "returns without blocking after writing as many bytes as it can > > immediately flush" is vague, and more or less intentionally so. The > > intent it really "writes as much as is convenient, with the guarantee > > that anything written is completely flushed". Maybe the documentation > > should be revised to say something more like that. > > > > There's not intended to be a guarantee that as much is written as could > > possibly make sense by `write-bytes-avail`. Implementation issues may > > make writing additional bytes inconvenient enough that it doesn't > > happen, for example, even if more is always written on the next > > `write-bytes-avail*` call. Also, ports are meant to be used in > > concurrent settings where the notion "as much as possible" is prone to > > race conditions. > > Dumb question ... why should non-blocking I/O worry about "flush" at > all. Why not behave like native I/O where writes are guaranteed only to > get to the I/O buffer? > > > > The Racket BC and CS pipe implementations find different things > > convenient, in this sense, and that's why they behave differently in > > the example. (That is, it's not really about the Racket version, but CS > > versus BC.) > > > > So, the intent is that you use `write-bytes` when you want to wait > > until all bytes are written (maybe because you know that will be soon > > enough, for whatever reason). But when using `write-bytes-avail`, be > > prepared for a fraction of the bytes to be written, for whatever > > reason. > > It is not a problem, per se, but it is an issue that with a long string, > you may be forced to call write-bytes-avail multiple times just to be > filling up the port buffer. That seems very inefficient and is at odds > with how native non-blocking I/O calls behave (completing or filling the > buffer before returning). > > YMMV, > George > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/5257581b-e863-2a2c-e3a3-802b79016281%40comcast.net. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAMTzy%2BbU4i7Rb28HuY%3DTGh0GdHMATdJrM7pjto5jD9h%2Bf_VxOw%40mail.gmail.com.
