[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Nonblocking get-bytevector-n bug?
From: |
Ludovic Courtès |
Subject: |
Re: Nonblocking get-bytevector-n bug? |
Date: |
Mon, 07 Dec 2015 10:50:51 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Marko Rauhamaa <address@hidden> skribis:
> Of these, only get-bytevector-some seems to behave as expected when the
> port is nonblocking:
>
> ========================================================================
> (use-modules (rnrs io ports)
> (rnrs bytevectors))
>
> (let ((port (fdes->inport 0)))
> (fcntl port F_SETFL (logior O_NONBLOCK (fcntl port F_GETFL)))
> (let loop ()
> (catch 'system-error
> (lambda ()
> (format #t "~s\n" (get-bytevector-some port)))
> (lambda syserr
> (format #t "err ~s\n" (system-error-errno syserr))))
> (sleep 1)
> (loop)))
> ========================================================================
>
> If you replace (get-bytevector-some port) with
> (get-bytevector-n port 8192) or (get-bytevector-n! port bv 0 8192),
> no partial data is returned.
That’s because get-bytevector-n{,!} are specified as blocking if
necessary until N bytes are read or EOF is reached.
> The problem with get-bytevector-some is that there is no limit to how
> many bytes might be returned. In practice, I see that the amount is
> capped at 4096 bytes, but the documentation does not guarantee any
> limit.
Right, the R6RS specification of that procedure doesn’t tell anything
more either.
It was criticized back in the day partly for that reason:
http://www.r6rs.org/formal-comments/comment-224.txt
I think a ‘get-bytevector-some!’ procedure could address the issue.
Not sure what R7 does here.
Thoughts?
Ludo’.
Re: Nonblocking get-bytevector-n bug?, Amirouche Boubekki, 2015/12/07
Re: Nonblocking get-bytevector-n bug?, Mark H Weaver, 2015/12/08