From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Marko Rauhamaa Newsgroups: gmane.lisp.guile.user Subject: Re: Nonblocking get-bytevector-n bug? Date: Mon, 07 Dec 2015 13:15:01 +0200 Message-ID: <87610abjd6.fsf@elektro.pacujo.net> References: <87h9jvuxb3.fsf@elektro.pacujo.net> <87poyilh8k.fsf@gnu.org> <87h9jubli1.fsf@elektro.pacujo.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1449486944 18792 80.91.229.3 (7 Dec 2015 11:15:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Dec 2015 11:15:44 +0000 (UTC) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Dec 07 12:15:44 2015 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a5tlC-0005cL-TG for guile-user@m.gmane.org; Mon, 07 Dec 2015 12:15:15 +0100 Original-Received: from localhost ([::1]:53849 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5tlC-0004Jn-1X for guile-user@m.gmane.org; Mon, 07 Dec 2015 06:15:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5tl2-0004IT-RW for guile-user@gnu.org; Mon, 07 Dec 2015 06:15:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a5tl1-0008Rf-QW for guile-user@gnu.org; Mon, 07 Dec 2015 06:15:04 -0500 Original-Received: from [2001:1bc8:1a0:5384:7a2b:cbff:fe9f:e508] (port=57619 helo=pacujo.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5tl1-0008R5-Hv for guile-user@gnu.org; Mon, 07 Dec 2015 06:15:03 -0500 Original-Received: from elektro.pacujo.net (192.168.1.200) by elektro.pacujo.net; Mon, 7 Dec 2015 13:15:01 +0200 Original-Received: by elektro.pacujo.net (sSMTP sendmail emulation); Mon, 07 Dec 2015 13:15:01 +0200 In-Reply-To: <87h9jubli1.fsf@elektro.pacujo.net> (Marko Rauhamaa's message of "Mon, 07 Dec 2015 12:28:54 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:1bc8:1a0:5384:7a2b:cbff:fe9f:e508 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:12221 Archived-At: Marko Rauhamaa : > ludo@gnu.org (Ludovic Court=C3=A8s): >> That=E2=80=99s because get-bytevector-n{,!} are specified as blocking if >> necessary until N bytes are read or EOF is reached. > > Ok, the Guile manual description leaves it a ambiguous. Even the R6RS > wording could be graciously bent slightly to support the age-old > nonblocking semantics. It boils down to what bytes are considered > "available." I don't think any nonblocking application would mind those > functions returning immediately with what they managed to read. In fact, I think Guile definitely *should* bend the R6RS specification because: 1. Guile 2.0's get-bytevector-n(!) does not comply with the strict R6RS reading anyway. The Guile implementation comes out with a system-error (EAGAIN) exception in case a nonblocking port does not have any bytes available at the moment. A strict reading would entail spinning in a tight loop, which would be silly, of course. 2. Partial reads throw a system-error (EAGAIN) and lose the already read bytes, which makes Guile's get-bytevector-n(!) completely unusable for nonblocking ports. 3. The R6RS wording suggests nonblocking ports were simply overlooked. A looser interpretation could be considered compliant. So, I think get-bytevector-n(!) could become useful if: A. If count bytes are available at the moment, follow the spec (no change to Guile 2.0.11). B. If eof is encountered, follow the spec (no change to Guile 2.0.11). C. If no bytes are available at the moment, a system-error (EGAIN) exception is thrown (no change to Guile 2.0.11). D. If some but fewer than count bytes are available at the moment, transfer those bytes and return the number of bytes transferred. Only item D is new. Wouldn't implementing it have only positives and no negatives? In fact, without it, how could nonblocking I/O be carried out effectively? Note also get-u8 and get-char, which *are* usefully implemented by Guile for nonblocking ports but are similarly in violation of R6RS (they don't block until a byte or complete character is available or eof is reached). Marko