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: Tue, 27 Feb 2007 10:27:07 +1100 Message-ID: <87slcsfqk4.fsf@zip.com.au> References: <87mz34ol6r.fsf@laas.fr> <87abz13kxl.fsf@zip.com.au> <877iu59fm8.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 1172532457 4678 80.91.229.12 (26 Feb 2007 23:27:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 26 Feb 2007 23:27:37 +0000 (UTC) To: Guile-Devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Feb 27 00:27:29 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 1HLpFf-0004vE-9H for guile-devel@m.gmane.org; Tue, 27 Feb 2007 00:27:27 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HLpFf-0005wr-91 for guile-devel@m.gmane.org; Mon, 26 Feb 2007 18:27:27 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HLpFb-0005wR-LA for guile-devel@gnu.org; Mon, 26 Feb 2007 18:27:23 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HLpFZ-0005u4-TZ for guile-devel@gnu.org; Mon, 26 Feb 2007 18:27:23 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HLpFZ-0005u1-N6 for guile-devel@gnu.org; Mon, 26 Feb 2007 18:27:21 -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 1HLpFY-0007qO-P7 for guile-devel@gnu.org; Mon, 26 Feb 2007 18:27:21 -0500 Original-Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id 036106E2D9 for ; Tue, 27 Feb 2007 10:27:13 +1100 (EST) Original-Received: from localhost (ppp2E0B.dyn.pacific.net.au [61.8.46.11]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id BC8348C23 for ; Tue, 27 Feb 2007 10:27:15 +1100 (EST) Original-Received: from gg by localhost with local (Exim 4.63) (envelope-from ) id 1HLpFM-0001i3-DK for guile-devel@gnu.org; Tue, 27 Feb 2007 10:27:08 +1100 Mail-Copies-To: never In-Reply-To: <877iu59fm8.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?= message of "Mon, 26 Feb 2007 15:07:43 +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:6573 Archived-At: ludovic.courtes@laas.fr (Ludovic Court=E8s) writes: > > Right. That's an incompatible change if the _output_ is buffered. > Input can be buffered, though, without this being visible by users. Alas, that too is in an incompatible change, because recv! ignores buffering. > Fortunately, port buffering doesn't have to be symmetrical (although the > API allowing to do that is internal---actually, we might want to expose > and document `scm_fport_buffer_add ()'). Sounds good. Perhaps `setvbuf-input' and `setvbuf-output' for the two directions. They could go in 1.8 too if you're careful with the implementation. Might have to check the SCM_BUFLINE and SCM_BUF0 flags are ok though. Suspect the answer is yes, SCM_BUFLINE being an output side feature, and SCM_BUF0 already merely a combination read=3D=3Dunbuf + write=3D=3Dunbu= f. > Thus, I propose the following > change, where sockets are turned into ports whose output is left > unbuffered and whose input is buffered. The manual could emphasise that unbuffered is not what you want if reading piecemeal, but the default should stay as advertised. > BTW, do you know what the purpose of `fport_wait_for_input ()' is? Maybe left from the 1.6 cooperative threads. > It > does nothing for O_NONBLOCK streams and waits for events otherwise. > Since, for blocking streams, `read ()' does not return until either EOF > is reached or at least one octet was read, `fport_wait_for_input ()' > seems redundant. Ahh, hang on, I wonder if it's a hack to do an "exit guile" while blocked within a read(), thus allowing gc to run in other threads. If that's true then presumably the write side is afflicted too, as well as various other potentially blocking operations like read-string!/partial and gethost. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel