From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Wingo Subject: Re: RPC performance Date: Mon, 26 Jun 2017 16:19:30 +0200 Message-ID: References: <20170527105641.9426-1-mail@cbaines.net> <871sr0ok2h.fsf@gnu.org> <8760gbh2th.fsf@gnu.org> <87efuym57c.fsf@gnu.org> <87a85kt7ad.fsf_-_@gnu.org> <87a85hnvqm.fsf@gnu.org> <87tw3lyz7t.fsf@inria.fr> <87poe4c5y9.fsf_-_@gnu.org> <87fuezkquf.fsf@gnu.org> <87lgoq8ch8.fsf@gnu.org> <87k2497kk7.fsf@elephly.net> <87vans1k5e.fsf_-_@inria.fr> <87poe01jgo.fsf@gnu.org> <87o9tg5dbm.fsf@igalia.com> <87injoc8jw.fsf@inria.fr> <87y3sjawf1.fsf@inria.fr> <87mv8v55ia.fsf@inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39658) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dPUrg-0007Ww-HM for guix-devel@gnu.org; Mon, 26 Jun 2017 10:19:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dPUrd-00030i-Cu for guix-devel@gnu.org; Mon, 26 Jun 2017 10:19:44 -0400 Received: from pb-sasl1.pobox.com ([64.147.108.66]:51240 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dPUrd-0002zp-7G for guix-devel@gnu.org; Mon, 26 Jun 2017 10:19:41 -0400 In-Reply-To: <87mv8v55ia.fsf@inria.fr> ("Ludovic =?utf-8?Q?Court=C3=A8s=22?= =?utf-8?Q?'s?= message of "Mon, 26 Jun 2017 13:54:05 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org On Mon 26 Jun 2017 13:54, ludovic.courtes@inria.fr (Ludovic Court=C3=A8s) w= rites: > Andy Wingo skribis: > >> Hi! >> >> On Fri 23 Jun 2017 11:24, ludovic.courtes@inria.fr (Ludovic Court=C3=A8s= ) writes: >> >>> With the current protocol, often we=E2=80=99re just reading a handful o= f 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) Note that get-bytevector-n will block until there are 8 bytes. > I see read(2) hanging on an 8K read: > > #0 0x00007fb0b36baaed in read () at ../sysdeps/unix/syscall-template.S:84 > #1 0x00007fb0b3b91c47 in fport_read (port=3D, dst=3D, start=3D,=20 > count=3D8192) at fports.c:604 > #2 0x00007fb0b3bbed77 in scm_i_read_bytes (port=3Dport@entry=3D0x194f700= , dst=3D0x195c000, start=3Dstart@entry=3D0,=20 > count=3D8192) at ports.c:1544 > #3 0x00007fb0b3bc25fe in scm_fill_input (port=3Dport@entry=3D0x194f700, = minimum_size=3D1, minimum_size@entry=3D0,=20 > cur_out=3Dcur_out@entry=3D0x7ffd7eee5f30, avail_out=3Davail_out@entry= =3D0x7ffd7eee5f38) at ports.c:2677 Here this indicates that the buffer is empty, and that it's blocking on receiving *any* bytes at all. > (That=E2=80=99s not Guile-specific.) I agree that read(2) could return l= ess > than 8K and not block, but it doesn=E2=80=99t have to. I think this is incorrect. Read returns when it has any bytes at all. >From read(2): It is not an error if this number is smaller than the number of bytes requested; this may happen for example because fewer bytes are actually available right now (maybe because we were close to end-of-file, or because we are reading from a pipe, or from a terminal), or because read() was interrupted by a signal. See also NOTES. In short the reason read is blocking for you is that there are no bytes available -- if there were 8 bytes and only 8 bytes, the read(2) would return directly. If you have blocking problems related to 8K buffers, it's likely related to using get-bytevector-n inside CBIP read() functions. Andy