From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Nala Ginrut Newsgroups: gmane.lisp.guile.bugs Subject: bug#30066: 'get-bytevector-some' returns only 1 byte from unbuffered ports Date: Thu, 11 Jan 2018 00:58:31 +0800 Message-ID: References: <87zi5lrc3x.fsf@gnu.org> <87tvvtr9ge.fsf@gnu.org> <87fu7dptdn.fsf@igalia.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1515603442 15758 195.159.176.226 (10 Jan 2018 16:57:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 10 Jan 2018 16:57:22 +0000 (UTC) Cc: Ludovic =?UTF-8?Q?Court=C3=A8s?= , 30066@debbugs.gnu.org To: Andy Wingo Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Wed Jan 10 17:57:17 2018 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eZJgf-0003SC-9V for guile-bugs@m.gmane.org; Wed, 10 Jan 2018 17:57:13 +0100 Original-Received: from localhost ([::1]:53839 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZJie-00026w-Rl for guile-bugs@m.gmane.org; Wed, 10 Jan 2018 11:59:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZJiU-00026N-Mg for bug-guile@gnu.org; Wed, 10 Jan 2018 11:59:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eZJiQ-0007Z1-7C for bug-guile@gnu.org; Wed, 10 Jan 2018 11:59:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43329) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eZJiQ-0007YY-30 for bug-guile@gnu.org; Wed, 10 Jan 2018 11:59:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eZJiP-0005FW-JQ for bug-guile@gnu.org; Wed, 10 Jan 2018 11:59:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Nala Ginrut Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Wed, 10 Jan 2018 16:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30066 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 30066-submit@debbugs.gnu.org id=B30066.151560351820147 (code B ref 30066); Wed, 10 Jan 2018 16:59:01 +0000 Original-Received: (at 30066) by debbugs.gnu.org; 10 Jan 2018 16:58:38 +0000 Original-Received: from localhost ([127.0.0.1]:51226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eZJi2-0005Et-Gu for submit@debbugs.gnu.org; Wed, 10 Jan 2018 11:58:38 -0500 Original-Received: from mail-yb0-f176.google.com ([209.85.213.176]:37318) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eZJi1-0005Ef-EL for 30066@debbugs.gnu.org; Wed, 10 Jan 2018 11:58:37 -0500 Original-Received: by mail-yb0-f176.google.com with SMTP id p83so1272860yba.4 for <30066@debbugs.gnu.org>; Wed, 10 Jan 2018 08:58:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CrBwAVjyo+fphgT+M+EGeujjK0c30jGFk19XpcvHmAg=; b=Sl7/jqXdgYB62ddc4ElQDr8TyjV63xk0KFvyEQ08MmCmRocK1RYumjD8DNgfhauCnM 8PuguX/CS1ztiXC/yFvLNUZyZKPmBfVDpn4tSo/gV+NtrrwMNoIrrMKnfAmKr2KNPYpg J9fwOjDjs9VqrO4J7urEUWX6sYj7ol88BzR88CLuH7k3h2K0lD9UgIO1XhsWzBVb8SSM KFW7+eV/kwanYru3UDMhwSQKrlE13UwX7AR1HNwPuXjckz66orhvNk++yA7Qj83poX9g Ff2DlJ9ToP1smG15HVV7wFvnZzZSWh+Ai2MUZpuk41Ql2oOeU5TC1q84ao1zZ3eOMG8h bXQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CrBwAVjyo+fphgT+M+EGeujjK0c30jGFk19XpcvHmAg=; b=U08OxN9e8za9n4VL6YH/7S3fR2R4Umy8tbM1LqZCpDVuaF6u1wCDVhepBA8XjzAGM+ UbxDY3zdwjXwWC07NXYHgp1m0Mi7QBf/tUPsdBsjLJJNiCy9rGe134MB23KBoEQW+nbT 2suEDlZPTEOG6CyDnBQwbhIpuar0/kxPH963Ubt1CL6xS0K9pzC49ZRlotsK3kH7roc4 5WInKmzhq7BDQaamEwMxGnNix+6RrpnIHT3vlmvMjlohErZYqBHmBQdPooJ+9FJWuyQt 8zhWqedvrdKBSmgYBtqlQLBw8W8ImKvOiuc79b20NERe/wUzq9dHOWJMpil9skysTjYh SVdQ== X-Gm-Message-State: AKGB3mKG81mqkFzSteM2B1wh12SoBFMOqevx3hKi6+WsT1rUmfRYaT5s 39exzlqGAKK2SUhwSUyijuy6/guN6W3A3KNxrpE= X-Google-Smtp-Source: ACJfBoswuk/Hmq4OVL302o1y/DdeUkWXtO14b3cXRHBcGb/XaJti0rgKHFA466wo4fUS/lWU4DimtBzMaOHEaG5PYAQ= X-Received: by 10.37.130.9 with SMTP id q9mr17369329ybk.397.1515603511837; Wed, 10 Jan 2018 08:58:31 -0800 (PST) Original-Received: by 10.37.11.137 with HTTP; Wed, 10 Jan 2018 08:58:31 -0800 (PST) In-Reply-To: <87fu7dptdn.fsf@igalia.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.org gmane.lisp.guile.bugs:8954 Archived-At: hi Andy and Ludo! What if developers enabled suspendable-ports and set the port to non-blocki= ng? For example, in the non-blocking asynchronous server, I registered read/write waiter for suspendable-ports. And save delimited-continuations then yield the current task. In this situation, get-bytevector-n! will read n bytes with several times yielding by the registered read-writer, from the caller's perspective, get-bytevector-n! will return n bytes finally no matter how many times it's yielded. But how about the get-bytevector-some? Should it block just once and return the first time read m bytes then return? Thanks! On Thu, Jan 11, 2018 at 12:32 AM, Andy Wingo wrote: > On Wed 10 Jan 2018 16:59, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> ludo@gnu.org (Ludovic Court=C3=A8s) skribis: >> >>> As discussed on IRC, =E2=80=98get-bytevector-some=E2=80=99 returns only= 1 byte from >>> unbuffered ports: >> >> Here=E2=80=99s a tentative fix. WDYT? > > Thanks! Needs a little work though :) Comments inline. > >> --- a/libguile/ports.h >> +++ b/libguile/ports.h >> @@ -69,6 +69,7 @@ SCM_INTERNAL SCM scm_i_port_weak_set; >> #define SCM_OPOUTPORTP(x) (SCM_OPPORTP (x) && SCM_OUTPUT_PORT_P (x)) >> #define SCM_OPENP(x) (SCM_OPPORTP (x)) >> #define SCM_CLOSEDP(x) (!SCM_OPENP (x)) >> +#define SCM_UNBUFFEREDP(x) (SCM_PORTP (x) && (SCM_CELL_WORD_0 (x) & SCM= _BUF0)) >> #define SCM_CLR_PORT_OPEN_FLAG(p) \ >> SCM_SET_CELL_WORD_0 ((p), SCM_CELL_WORD_0 (p) & ~SCM_OPN) >> #ifdef BUILDING_LIBGUILE > > Please guard this under #ifdef BUILDING_LIBGUILE. > >> @@ -487,16 +487,33 @@ SCM_DEFINE (scm_get_bytevector_some, "get-bytevect= or-some", 1, 0, 0, >> >> SCM_VALIDATE_BINARY_INPUT_PORT (1, port); >> >> - buf =3D scm_fill_input (port, 0, &cur, &avail); >> - if (avail =3D=3D 0) >> + if (SCM_UNBUFFEREDP (port)) >> { >> - scm_port_buffer_set_has_eof_p (buf, SCM_BOOL_F); >> - return SCM_EOF_VAL; >> + size_t read; >> + >> + bv =3D scm_c_make_bytevector (4096); >> + read =3D scm_i_read_bytes (port, bv, 0, SCM_BYTEVECTOR_LENGTH (bv= )); >> + >> + if (read =3D=3D 0) >> + return SCM_EOF_VAL; >> + else if (read < SCM_BYTEVECTOR_LENGTH (bv)) >> + return scm_c_shrink_bytevector (bv, read); >> + else >> + return bv; >> } >> + else >> + { >> + buf =3D scm_fill_input (port, 0, &cur, &avail); >> + if (avail =3D=3D 0) >> + { >> + scm_port_buffer_set_has_eof_p (buf, SCM_BOOL_F); >> + return SCM_EOF_VAL; >> + } >> >> - bv =3D scm_c_make_bytevector (avail); >> - scm_port_buffer_take (buf, (scm_t_uint8 *) SCM_BYTEVECTOR_CONTENTS (b= v), >> - avail, cur, avail); >> + bv =3D scm_c_make_bytevector (avail); >> + scm_port_buffer_take (buf, (scm_t_uint8 *) SCM_BYTEVECTOR_CONTENT= S (bv), >> + avail, cur, avail); >> + } >> >> return bv; >> } > > There are tabs in your code; would you mind doing only spaces? > > A port being unbuffered doesn't mean that it has no bytes in its > buffer. In particular, scm_unget_bytes may put bytes back into the > buffer. Or, peek-u8 might fill this buffer with one byte. > > Also, they port may have buffered write bytes (could be the port has > write buffering but no read buffering). In that case (pt->rw_random) > you need to scm_flush(). > > I suggest taking the buffered bytes from the read buffer, if any. Then > if the port is unbuffered, make a bytevector and call scm_i_read_bytes; > otherwise do the scm_fill_input path that's there already. > > One more thing, if the port goes EOF, you need to > scm_port_buffer_set_has_eof_p. > > Regards, > > Andy > > >