unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Neil Jerram <neil@ossau.uklinux.net>
Cc: guile-devel@gnu.org, ldv@altlinux.org
Subject: Re: guile-1.8.1 - problems on AMD64
Date: Thu, 19 Oct 2006 19:46:24 +0100	[thread overview]
Message-ID: <871wp43zzz.fsf@ossau.uklinux.net> (raw)
In-Reply-To: <873b9ou1nw.fsf@laas.fr> ( Ludovic Courtès's message of "Mon, 16 Oct 2006 10:04:35 +0200")

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> I guess the point of this `_FORTIFY_SOURCE' thing is to help catch
> errors related to interactions with the kernel (among others).  The idea
> is that when performing a system call, one _should_ be concerned about
> its result.
>
> In the case of async.c:250, I don't understand whether/how failure of
> the `write ()' call should be handled.

I think it's writing a byte as an inter-thread signaling mechanism.
It's pretty unlikely that a single byte write will be interrupted, but
if it is then a retry will be needed, so I think the use of
SCM_SYSCALL is correct in principle here.

How about this, which is more similarly to the other uses of
SCM_SYSCALL in the code?

      SCM_SYSCALL (rv = write (sleep_fd, &dummy, 1));

(Whole patch is below.)

Regards,
     Neil


Index: async.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/async.c,v
retrieving revision 1.86
diff -u -r1.86 async.c
--- async.c	17 Apr 2006 00:05:37 -0000	1.86
+++ async.c	19 Oct 2006 18:46:32 -0000
@@ -241,13 +241,14 @@
   if (sleep_fd >= 0)
     {
       char dummy = 0;
+      int rv;
       /* Likewise, T might already been done with sleeping here, but
 	 interrupting it once too often does no harm.  T might also
 	 not yet have started sleeping, but this is no problem either
 	 since the data written to a pipe will not be lost, unlike a
 	 condition variable signal.
       */
-      write (sleep_fd, &dummy, 1);
+      SCM_SYSCALL (rv = write (sleep_fd, &dummy, 1));
     }
 
   /* This is needed to protect sleep_mutex.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


  reply	other threads:[~2006-10-19 18:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-10  6:34 guile-1.8.1 - problems on AMD64 Stanislav Ievlev
2006-10-10  8:23 ` Ludovic Courtès
2006-10-11 11:01   ` Stanislav Ievlev
2006-10-11 20:08     ` Kevin Ryde
2006-10-12 12:58     ` Ludovic Courtès
2006-10-13  6:26       ` Stanislav Ievlev
2006-10-13  7:38         ` Ludovic Courtès
2006-10-14 13:13           ` Neil Jerram
2006-10-16  6:25             ` Stanislav Ievlev
2006-10-16  8:04               ` Ludovic Courtès
2006-10-19 18:46                 ` Neil Jerram [this message]
2006-10-21 13:12                   ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871wp43zzz.fsf@ossau.uklinux.net \
    --to=neil@ossau.uklinux.net \
    --cc=guile-devel@gnu.org \
    --cc=ldv@altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).