[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RPC performance
From: |
Andy Wingo |
Subject: |
Re: RPC performance |
Date: |
Fri, 23 Jun 2017 11:46:01 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Hi!
On Fri 23 Jun 2017 11:24, address@hidden (Ludovic Courtès) writes:
> With the current protocol, often we’re just reading a handful of bytes.
> Full buffering would mean that Guile would block on an 8K read or so
> that will never be fulfilled.
That's not how it works :) The "read" function of a port should only
block if no byte can be read. If 1K bytes are available for an 8K
buffer, then the read function should return after filling only 1K
bytes; looping to fill at least 8K is some other code's responsibility.
In particular, "read" functions should not use get-bytevector-n, as
get-bytevector-n is defined to block until N bytes are available.
Instead they should use get-bytevector-some. See:
https://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.2&id=0c102b56e98da39b5a3213bdc567a31ad8ef3e73
Andy
- Re: Performance on NFS, (continued)
- Re: Performance on NFS, Ludovic Courtès, 2017/06/17
- Re: Performance on NFS, Roel Janssen, 2017/06/17
- Re: Performance on NFS, Ricardo Wurmus, 2017/06/18
- RPC performance, Ludovic Courtès, 2017/06/19
- Re: RPC performance, Ludovic Courtès, 2017/06/19
- Re: RPC performance, Ricardo Wurmus, 2017/06/19
- Re: RPC performance, Andy Wingo, 2017/06/22
- Re: RPC performance, Ludovic Courtès, 2017/06/22
- Re: RPC performance, Andy Wingo, 2017/06/23
- Re: RPC performance, Ludovic Courtès, 2017/06/23
- Re: RPC performance,
Andy Wingo <=
- Re: RPC performance, Ludovic Courtès, 2017/06/26
- Re: RPC performance, Andy Wingo, 2017/06/26
- Re: RPC performance, Ludovic Courtès, 2017/06/19
- Re: RPC performance, Ricardo Wurmus, 2017/06/22
- Re: Combining Guix, direnv and Emacs for environment customisation, Ricardo Wurmus, 2017/06/07
- Performance on NFS, Ludovic Courtès, 2017/06/07
- Re: Performance on NFS, Ricardo Wurmus, 2017/06/07