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.devel Subject: Re: SCM_SYSCALL Date: Wed, 03 Jul 2013 14:19:24 -0400 Message-ID: <878v1nfqvn.fsf@tines.lan> References: <87li607c5l.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1372875611 27426 80.91.229.3 (3 Jul 2013 18:20:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Jul 2013 18:20:11 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Jul 03 20:20:13 2013 Return-path: Envelope-to: guile-devel@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 1UuReu-0008BD-TV for guile-devel@m.gmane.org; Wed, 03 Jul 2013 20:20:05 +0200 Original-Received: from localhost ([::1]:55516 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuReu-0001Z6-A9 for guile-devel@m.gmane.org; Wed, 03 Jul 2013 14:20:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48432) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuRem-0001Tt-3e for guile-devel@gnu.org; Wed, 03 Jul 2013 14:19:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UuRej-0002Ca-OU for guile-devel@gnu.org; Wed, 03 Jul 2013 14:19:55 -0400 Original-Received: from world.peace.net ([96.39.62.75]:34205) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuRej-00027I-GS; Wed, 03 Jul 2013 14:19:53 -0400 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UuReR-0002Wh-QZ; Wed, 03 Jul 2013 14:19:36 -0400 In-Reply-To: <87li607c5l.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sun, 23 Jun 2013 23:25:10 +0200") 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-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16510 Archived-At: Hi Ludovic, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > We have this (since 2010): > > # define SCM_SYSCALL(line) \ > do \ > { \ > errno =3D 0; \ > line; \ > if (errno =3D=3D EINTR) \ > { \ > SCM_ASYNC_TICK; \ > continue; \ > } \ > } \ > while(0) > > It turns out that the effect upon EINTR is to leave the loop. So > typically, fport_fill_input just throws to system-error and reveals the > EINTR, contrary to SCM_SYSCALL intends to do. Ugh. Well, I guess this finally explains . Thanks for tracking this down. > This is easily fixed, but the question is whether this would affect > users in bad ways. For example, applications might be relying on the > ability to do > > (catch 'system-error > ... > (lambda args > (if (=3D EINTR (system-error-errno args)) > ...))) > > Should the fix be delayed until 2.2? > WDYT? I strongly believe that we should fix this in stable-2.0. While it is true that the above scenario is possible, I suspect it is at least an order of magnitude more common for Guile-based software to be written based on the presumption that EINTR is handled automatically. Not only did all versions of Guile 1.x automatically handle EINTR, but most of us assumed that this behavior was unchanged in Guile 2.0 and wrote our software based on that assumption. I certainly did. As it is now, even portable Scheme code that uses (read) might result in exceptions being thrown semi-randomly. We cannot reasonably expect Guile programs to put each (read) within a loop to handle EINTR. Please, let's fix this in stable-2.0. What do you think? Mark