Re: RPC performance

[ludovic.courtes@inria.fr (Ludovic Courtès)]

Andy Wingo <wingo@igalia.com> skribis:

> Hi!
>
> On Fri 23 Jun 2017 11:24, ludovic.courtes@inria.fr (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.

I must be missing something.  With full buffering, when my code does:

  (get-bytevector-n port 8)

I see read(2) hanging on an 8K read:

--8<---------------cut here---------------start------------->8---
#0  0x00007fb0b36baaed in read () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007fb0b3b91c47 in fport_read (port=<optimized out>, dst=<optimized out>, start=<optimized out>, 
    count=8192) at fports.c:604
#2  0x00007fb0b3bbed77 in scm_i_read_bytes (port=port@entry=0x194f700, dst=0x195c000, start=start@entry=0, 
    count=8192) at ports.c:1544
#3  0x00007fb0b3bc25fe in scm_fill_input (port=port@entry=0x194f700, minimum_size=1, minimum_size@entry=0, 
    cur_out=cur_out@entry=0x7ffd7eee5f30, avail_out=avail_out@entry=0x7ffd7eee5f38) at ports.c:2677
#4  0x00007fb0b3bc3384 in scm_c_read_bytes (port=port@entry=0x194f700, dst=dst@entry=0x1952510, 
    start=start@entry=0, count=count@entry=8) at ports.c:1610
#5  0x00007fb0b3bc9838 in scm_get_bytevector_n (port=0x194f700, count=<optimized out>) at r6rs-ports.c:421
#6  0x00007fb0b3bfdc4d in vm_regular_engine (thread=0xe, vp=0x143df30, registers=0x2000, resume=-1284789523)
    at vm-engine.c:784
--8<---------------cut here---------------end--------------->8---

(That’s not Guile-specific.)  I agree that read(2) could return less
than 8K and not block, but it doesn’t have to.

I’ll see if I can investigate more later.

Thanks for your input,
Ludo’.