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 <gneun...@comcast.net> 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 racket-users+unsubscr...@googlegroups.com. > 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 racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAMTzy%2BbU4i7Rb28HuY%3DTGh0GdHMATdJrM7pjto5jD9h%2Bf_VxOw%40mail.gmail.com.
