From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.user Subject: Re: asynchronous socket library Date: Wed, 17 Jul 2013 03:13:33 -0400 Message-ID: <8738rd1wwy.fsf@tines.lan> References: <8761w9n2i6.fsf@mark-desktop.PK5001Z> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1374045253 31480 80.91.229.3 (17 Jul 2013 07:14:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Jul 2013 07:14:13 +0000 (UTC) Cc: guile-user@gnu.org To: mark@markwitmer.com Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Jul 17 09:14:14 2013 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 1UzLwD-000710-Kg for guile-user@m.gmane.org; Wed, 17 Jul 2013 09:14:13 +0200 Original-Received: from localhost ([::1]:42045 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzLwD-0006wC-6Q for guile-user@m.gmane.org; Wed, 17 Jul 2013 03:14:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40818) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzLw5-0006vt-RU for guile-user@gnu.org; Wed, 17 Jul 2013 03:14:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UzLw4-0003yE-EV for guile-user@gnu.org; Wed, 17 Jul 2013 03:14:05 -0400 Original-Received: from world.peace.net ([96.39.62.75]:55372) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzLw4-0003y8-Bf for guile-user@gnu.org; Wed, 17 Jul 2013 03:14:04 -0400 Original-Received: from 209-6-120-240.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com ([209.6.120.240] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UzLvv-0004qy-Eo; Wed, 17 Jul 2013 03:13:55 -0400 In-Reply-To: <8761w9n2i6.fsf@mark-desktop.PK5001Z> (mark@markwitmer.com's message of "Tue, 16 Jul 2013 23:07:13 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 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:10552 Archived-At: mark@markwitmer.com writes: > Reading and writing to a socket seems to lend itself well to custom > binary ports, Why do you say that? For most purposes, Guile's native file ports are superior, and they seem the natural choice for sockets. > but then I think you're stuck with an opaque buffer -- you > can't properly ask the binary port if the next read beyond one byte will > block or not, since it might have stuff buffered or it might not. I'd > love to be wrong about that if someone happens to know how to check for > the amount remaining in a custom binary port's buffer. 'get-bytevector-some' from (rnrs io ports) might do what you need. If there's at least one byte available it will not block, but in practice it reads much more than that (for buffered ports). Guile 2.0.9 has a nice fast implementation. Prior to 2.0.9, it was less so. In more detail: as of 2.0.9, 'get-bytevector-some' will simply copy the input buffer managed by Guile into a bytevector and return it. If Guile's input buffer is empty, it will try to refill the buffer using the port type's 'fill_input' method. For file ports this is fports.c:fport_fill_input, and for custom binary ports it's r6rs-ports.c:cbip_fill_input. Prior to 2.0.9, 'get-bytevector-some' was instead implemented as a loop that repeatedly called 'char-ready?' and read one byte at a time. This would drain more than just Guile's buffer; it would try to drain the upstream buffers as well. However, 'char-ready?', and thus the pre-2.0.9 'byte-vector-some', depend upon the port type providing an 'input_waiting' method. File ports provide this, implemented using 'poll' with 0 timeout, see fports.c:fport_input_waiting. Unfortunately, custom binary ports do NOT provide an 'input_waiting' method, so 'char-ready?' always returns true, and I guess this ultimately means that the pre-2.0.9 'get-bytevector-some' will block until it reaches EOF. So again I ask, why use custom binary ports for sockets? Regards, Mark