From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludovic.courtes@laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: Unbuffered socket I/O Date: Thu, 01 Mar 2007 10:10:19 +0100 Organization: LAAS-CNRS Message-ID: <87wt21cosk.fsf@laas.fr> References: <87mz34ol6r.fsf@laas.fr> <87abz13kxl.fsf@zip.com.au> <877iu59fm8.fsf@laas.fr> <87odng64o3.fsf@ossau.uklinux.net> <87irdox8w7.fsf@laas.fr> <87d53u7z6k.fsf@zip.com.au> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1172740258 13609 80.91.229.12 (1 Mar 2007 09:10:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 1 Mar 2007 09:10:58 +0000 (UTC) Cc: Guile-Devel To: Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Mar 01 10:10:50 2007 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HMhJJ-0001sw-Rb for guile-devel@m.gmane.org; Thu, 01 Mar 2007 10:10:50 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HMhJL-0008SD-6V for guile-devel@m.gmane.org; Thu, 01 Mar 2007 04:10:51 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HMhIu-0008Q1-Vx for guile-devel@gnu.org; Thu, 01 Mar 2007 04:10:25 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HMhIt-0008Pb-Cq for guile-devel@gnu.org; Thu, 01 Mar 2007 04:10:24 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HMhIs-0008PT-Vn for guile-devel@gnu.org; Thu, 01 Mar 2007 04:10:23 -0500 Original-Received: from laas.laas.fr ([140.93.0.15]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1HMhIs-0001AO-BK for guile-devel@gnu.org; Thu, 01 Mar 2007 04:10:22 -0500 Original-Received: from messiaen.laas.fr (messiaen [IPv6:2001:660:6602:0:230:65ff:fed4:9d20]) by laas.laas.fr (8.13.8/8.13.8) with SMTP id l219AF8w015490; Thu, 1 Mar 2007 10:10:19 +0100 (MET) Original-Received: by messiaen.laas.fr (sSMTP sendmail emulation); Thu, 01 Mar 2007 10:10:19 +0100 X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 11 =?iso-8859-1?Q?Vent=F4se?= an 215 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEB1F5364 X-PGP-Key: http://www.laas.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: powerpc-unknown-linux-gnu Mail-Followup-To: Neil Jerram , Guile-Devel In-Reply-To: <87d53u7z6k.fsf@zip.com.au> (Kevin Ryde's message of "Thu, 01 Mar 2007 08:24:51 +1100") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-Spam-Score: 0.306 () MAILTO_TO_SPAM_ADDR,NO_RELAYS X-Scanned-By: MIMEDefang at CNRS-LAAS on IPv6:2001:660:6602::2 X-MIME-Autoconverted: from 8bit to quoted-printable by laas.laas.fr id l219AF8w015490 X-detected-kernel: Solaris 10 (beta) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:6583 Archived-At: Hi, Kevin Ryde writes: > ludovic.courtes@laas.fr (Ludovic Court=E8s) writes: >> >> (uniform-vector-read! vec port))) > > Slackness in the implementation of that function. It knows a size to > read and should come out as a read() system call of that size. Yet it > always goes through the port buffer. I believe it's a feature, not some "slackness". ;-) The function is meant to read from _any_ kind of input port. Thus, it can definitely not use the `read ()' system call to that end. Instead, it rightfully uses one of the two public functions available to read from an arbitrary port: `scm_getc ()' and `scm_c_read ()'. > read-string!/partial is much better in that respect. Maybe that func > should be loosened up to work on non-fports too, that could be nice. > > It's a bit of a failing of the ptab port functions that there's no > "read N bytes", but that needn't prevent uniform-vector-read! doing > the right thing on fports. There's `scm_c_read ()' for "read N bytes", but it translates into N calls to `scm_getc ()'. If the port is unbuffered, then each invocation of `scm_getc ()' translates in one `scm_fill_input ()' call, which in turn translates in one `select ()' and one `read ()' of size 1. I think _this_ is the issue, not the fact that `uniform-vector-read!' can read from any kind of port. IMO it feels wrong to dismiss the port abstraction (e.g., by testing for fports and using fport-specific I/O methods) just to work around this performance problem. > Could also think if those calls should then cope with O_NONBLOCK > too, by sleeping in select() if finding there's nothing to read yet. > On a single read call I would say let it throw an error, but if the > aim is to block until the requested size then it's easy enough to > cope. I noticed that `fport_fill_input ()' would raise an error when reading from a non-blocking file descriptor where input is not available (i.e., when `read ()' returns -1 with ERRNO =3D=3D EWOULDBLOCK). Thus it must b= e inconvenient (at best) to use the port I/O functions on a port whose underlying FD is in non-blocking mode. I don't know what would need to be done to fix this. Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel