Andy Wingo <wi...@igalia.com> skribis:
> Hi!
>
> On Fri 23 Jun 2017 11:24, ludovic.cour...@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’.
