In case anyone else runs into this issue and is worried about their code
blocking forever, here's a version that will time out.  The only change is
the use of sync/timeout and value-evt.
https://docs.racket-lang.org/value-evt/index.html

(require value-evt)
(define bstr (make-shared-bytes 509 5))
(define rx-pipe-size 16777216)
(define-values (rx-in rx-out) (make-pipe rx-pipe-size))

(define (room-in-rx-pipe? bstr)
  (define avail (- rx-pipe-size (pipe-content-length rx-out)))
  (displayln (format "avail: ~a" avail))
  (<= (bytes-length bstr) avail))

(displayln (format "space available? ~a " (room-in-rx-pipe? bstr)))
(displayln (format "pipe content length: ~a" (pipe-content-length rx-out)))

; if write-bytes takes more than 0.5 seconds then it will be interrupted
and num-bytes-written will end up being #f
; wrapping the write-bytes expressing in a thunk is important because we
don't want it to be evaluated before the sync
(define num-bytes-written (sync/timeout 0.5 (value-evt (thunk (write-bytes
bstr rx-out)))))
(unless (eq? num-bytes-written (bytes-length bstr))
  (displayln (format "rx buffer overflow. pipe content length: ~a, written
~a, expected ~a"
                     (pipe-content-length rx-out) num-bytes-written
(bytes-length bstr))))

(displayln "done")

-------- output
avail: 16777216
space available? #t
pipe content length: 0
done
test.r

On Wed, Jun 16, 2021 at 4:13 PM David Storrs <david.sto...@gmail.com> wrote:

> Got it. Thanks.
>
> On Wed, Jun 16, 2021 at 3:45 PM Matthew Flatt <mfl...@cs.utah.edu> 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.
>>
>> 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.
>>
>

-- 
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/CAE8gKocHjnCsVYcp7ubEvH_P7nX0xMzv4NmfyByeFZvSowtj2A%40mail.gmail.com.

Reply via email to