From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kevin Ryde Newsgroups: gmane.lisp.guile.devel Subject: Re: Unbuffered socket I/O Date: Thu, 01 Mar 2007 07:59:39 +1100 Message-ID: <874pp69ex0.fsf@zip.com.au> References: <87mz34ol6r.fsf@laas.fr> <87abz13kxl.fsf@zip.com.au> <877iu59fm8.fsf@laas.fr> <87slcsfqk4.fsf@zip.com.au> <87fy8qlik1.fsf@laas.fr> 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 1172696426 6624 80.91.229.12 (28 Feb 2007 21:00:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 28 Feb 2007 21:00:26 +0000 (UTC) To: Guile-Devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Feb 28 22:00:14 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 1HMVu7-0005sS-Vx for guile-devel@m.gmane.org; Wed, 28 Feb 2007 22:00:04 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HMVu8-0001it-CY for guile-devel@m.gmane.org; Wed, 28 Feb 2007 16:00:04 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HMVu4-0001iU-Ed for guile-devel@gnu.org; Wed, 28 Feb 2007 16:00:00 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HMVu3-0001iI-5Y for guile-devel@gnu.org; Wed, 28 Feb 2007 16:00:00 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HMVu3-0001iF-1X for guile-devel@gnu.org; Wed, 28 Feb 2007 15:59:59 -0500 Original-Received: from mailout2-8.pacific.net.au ([61.8.2.231] helo=mailout2.pacific.net.au) by monty-python.gnu.org with esmtp (Exim 4.52) id 1HMVu1-0007Ek-VZ for guile-devel@gnu.org; Wed, 28 Feb 2007 15:59:58 -0500 Original-Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id C3EEA109BFE for ; Thu, 1 Mar 2007 07:59:46 +1100 (EST) Original-Received: from localhost (ppp22F6.dyn.pacific.net.au [61.8.34.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 950412740E for ; Thu, 1 Mar 2007 07:59:49 +1100 (EST) Original-Received: from gg by localhost with local (Exim 4.63) (envelope-from ) id 1HMVtk-0001aw-Cj for guile-devel@gnu.org; Thu, 01 Mar 2007 07:59:40 +1100 Mail-Copies-To: never In-Reply-To: <87fy8qlik1.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?= message of "Wed, 28 Feb 2007 10:47:58 +0100") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) 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:6580 Archived-At: ludovic.courtes@laas.fr (Ludovic Court=E8s) writes: > > Below is a tentative patch (I chose more meaningful names since they > don't relate to `setvbuf(3)'). Call them setvbuf. Two names for the same thing is more confusing than one (slightly obscure) name. > Besides, how about applying the change I originally proposed to HEAD? No, principally because unbuffered is an advertised feature. Even if it was year zero you'd probably still choose them to start unbuffered, since there's various ways to do comms and it can be up to an application how much might be desirable. For block operations for instance it's certainly not wanted. > That would require changing `recv!', `send', etc. so that they are > somehow "buffering-aware". That could be ok. I doubt it makes much sense, because buffering is more or less stream oriented yet those funcs are about packets. But they could still look at the buffers in the interests of keeping data in sequence. > Afflicted by what? Blocking in one thread prevents gc in any other thread, bringing everything to a screeching halt, before long. > + "Use a @var{size}-octet Say "byte" not "octet". Octet sounds like one of those dreadful CCITT standards. > + size_t c_size; > + c_size =3D scm_to_uint (size); There's an scm_to_size_t for that. + if (c_offset > c_size) + scm_wrong_type_arg_msg (FUNC_NAME, 1, port, + "Input buffer must be flushed before it " + "can be shrunk"); The current code silently discards, I think that's probably enough. If it was up to me I might move it to the putback buffer though. > + if (c_size =3D=3D 0) > + new_buf =3D &pt->shortbuf, c_size =3D 1; I suppose an explicit request for size=3D=3D1 could use the shortbuf too, though I see the existing code doesn't do that. (Maybe there's a reason it doesn't.) I expect there's a memory leak there if you don't free the old buf when becoming unbuffered. > + if ((pt->read_buf_size =3D=3D 0) && (pt->write_buf_size =3D=3D 0)) > + SCM_SET_CELL_WORD_0 (port, SCM_CELL_WORD_0 (port) | SCM_BUF0); That'd need to turn the flag off too, if it's become non-zero. > + if (c_offset > c_size) > + scm_wrong_type_arg_msg (FUNC_NAME, 1, port, > + "Output buffer must be flushed before it " > + "can be shrunk"); That doesn't need to be an error does it? Can't it be flushed there and then? Otherwise looks ok as long as it actually works! :) _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel