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: Wed, 07 Mar 2007 11:20:44 +1100 Message-ID: <87wt1trjj7.fsf@zip.com.au> 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> <87wt21cosk.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 1173226866 19851 80.91.229.12 (7 Mar 2007 00:21:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 7 Mar 2007 00:21:06 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Mar 07 01:20:59 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 1HOjtq-0004Bx-PF for guile-devel@m.gmane.org; Wed, 07 Mar 2007 01:20:59 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HOjts-0007xD-Fy for guile-devel@m.gmane.org; Tue, 06 Mar 2007 19:21:00 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HOjtp-0007x8-Sl for guile-devel@gnu.org; Tue, 06 Mar 2007 19:20:57 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HOjtm-0007ww-13 for guile-devel@gnu.org; Tue, 06 Mar 2007 19:20:57 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HOjtl-0007wt-VA for guile-devel@gnu.org; Tue, 06 Mar 2007 19:20:53 -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.60) (envelope-from ) id 1HOjtj-0008LI-6c for guile-devel@gnu.org; Tue, 06 Mar 2007 19:20:51 -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 29E81111167 for ; Wed, 7 Mar 2007 11:20:43 +1100 (EST) Original-Received: from localhost (ppp2076.dyn.pacific.net.au [61.8.32.118]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 5FCED8C17 for ; Wed, 7 Mar 2007 11:20:46 +1100 (EST) Original-Received: from gg by localhost with local (Exim 4.63) (envelope-from ) id 1HOjtc-0002bD-TA for guile-devel@gnu.org; Wed, 07 Mar 2007 11:20:44 +1100 Mail-Copies-To: never In-Reply-To: <87wt21cosk.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?= message of "Thu, 01 Mar 2007 10:10:19 +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:6592 Archived-At: ludovic.courtes@laas.fr (Ludovic Court=E8s) writes: > > of `scm_getc ()' translates in one `scm_fill_input ()' call, which in > turn translates in one `select ()' and one `read ()' Coming back to this bit: that select really does seem pretty doubtful. The more I think the more it sounds like a hangover from 1.6 where select was the only proper place to block if other threads were to keep running. But maybe now the right thing would be to have the scm_leave_guile or scm_without_guile or whatever around each read/write. Avoiding initializing an fd_set and whatnot for select would have to be a good thing. If so then there'd be other places a similar leave might be wanted, `copy-file' and `gethost' for instance (I might have mentioned them before). Oh well, I guess there's plenty of work for anyone who wants to investigate ... One thing I'm pretty sure about though is that the __MINGW32__ conditional on fport_wait_for_input can't be right. I think we had bug reports that mingw has pthreads now, so surely anything wanted for pthreads will be wanted on mingw (or new enough ones or whatever). Maybe the condition was meant to be "if threads" instead of "if not mingw". If configured with null-threads then there'd be no need to worry about where any blocking happens. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel