[RFC] Block all async signals used by gdb when initializing Guile

2015-08-29 Thread Doug Evans
Hi.

When Guile initializes it will start several GC threads (libgc).
It's important that these threads block SIGCHLD (PR 17247).

This patch extends this to all async signals used by gdb.

One improvement on this patch would be to have event-top.c (or some
such) provide a routine that calls sigaddset for each appropriate
signal rather than defining the list in guile.c.

2015-08-29  Doug Evans  xdj...@gmail.com

* guile/guile.c (_initialize_guile): Block all asynchronous signals
used by gdb when initializing Guile.

diff --git a/gdb/guile/guile.c b/gdb/guile/guile.c
index 4abf5c5..e9ef70b 100644
--- a/gdb/guile/guile.c
+++ b/gdb/guile/guile.c
@@ -847,7 +847,7 @@ _initialize_guile (void)
 #if HAVE_GUILE
   {
 #ifdef HAVE_SIGPROCMASK
-sigset_t sigchld_mask, prev_mask;
+sigset_t guile_init_mask, prev_mask;
 #endif
 
 /* The Python support puts the C side in module _gdb, leaving the Python
@@ -867,9 +867,23 @@ _initialize_guile (void)
have SIGCHLD blocked.  PR 17247.
Really libgc and Guile should do this, but we need to work with
libgc 7.4.x.  */
-sigemptyset (sigchld_mask);
-sigaddset (sigchld_mask, SIGCHLD);
-sigprocmask (SIG_BLOCK, sigchld_mask, prev_mask);
+sigemptyset (guile_init_mask);
+sigaddset (guile_init_mask, SIGCHLD);
+/* Also block other asynchronous signals used by GDB.  See event-top.c.
+   Really we want to block every signal here except for those specifically
+   used by Guile (e.g., GC threads), but this is safer for now.  */
+sigaddset (guile_init_mask, SIGINT);
+sigaddset (guile_init_mask, SIGTERM);
+#ifdef SIGQUIT
+sigaddset (guile_init_mask, SIGQUIT);
+#endif
+#ifdef SIGHUP
+sigaddset (guile_init_mask, SIGHUP);
+#endif
+#ifdef SIGWINCH
+sigaddset (guile_init_mask, SIGWINCH);
+#endif
+sigprocmask (SIG_BLOCK, guile_init_mask, prev_mask);
 #endif
 
 /* scm_with_guile is the most portable way to initialize Guile.



Re: [RFC] Block all async signals used by gdb when initializing Guile

2015-08-29 Thread Eli Zaretskii
 From: Doug Evans xdj...@gmail.com
 cc: guile-devel@gnu.org
 Date: Sat, 29 Aug 2015 10:22:11 -0700
 
 --- a/gdb/guile/guile.c
 +++ b/gdb/guile/guile.c
 @@ -847,7 +847,7 @@ _initialize_guile (void)
  #if HAVE_GUILE
{
  #ifdef HAVE_SIGPROCMASK
 -sigset_t sigchld_mask, prev_mask;
 +sigset_t guile_init_mask, prev_mask;
  #endif
  
  /* The Python support puts the C side in module _gdb, leaving the 
 Python
 @@ -867,9 +867,23 @@ _initialize_guile (void)
 have SIGCHLD blocked.  PR 17247.
 Really libgc and Guile should do this, but we need to work with
 libgc 7.4.x.  */
 -sigemptyset (sigchld_mask);
 -sigaddset (sigchld_mask, SIGCHLD);
 -sigprocmask (SIG_BLOCK, sigchld_mask, prev_mask);
 +sigemptyset (guile_init_mask);
 +sigaddset (guile_init_mask, SIGCHLD);
 +/* Also block other asynchronous signals used by GDB.  See event-top.c.
 +   Really we want to block every signal here except for those 
 specifically
 +   used by Guile (e.g., GC threads), but this is safer for now.  */
 +sigaddset (guile_init_mask, SIGINT);
 +sigaddset (guile_init_mask, SIGTERM);
 +#ifdef SIGQUIT
 +sigaddset (guile_init_mask, SIGQUIT);
 +#endif
 +#ifdef SIGHUP
 +sigaddset (guile_init_mask, SIGHUP);
 +#endif
 +#ifdef SIGWINCH
 +sigaddset (guile_init_mask, SIGWINCH);
 +#endif
 +sigprocmask (SIG_BLOCK, guile_init_mask, prev_mask);
  #endif

What about platforms that don't have sigprocmask, but do have SIGINT?
Don't we want to block SIGINT on those platforms?



Re: [RFC] Block all async signals used by gdb when initializing Guile

2015-08-29 Thread Doug Evans
On Sat, Aug 29, 2015 at 1:16 PM, Eli Zaretskii e...@gnu.org wrote:
 Date: Sat, 29 Aug 2015 12:20:24 -0700
 From: Doug Evans xdj...@gmail.com
 Cc: gdb-patc...@sourceware.org gdb-patc...@sourceware.org, guile-devel 
 guile-devel@gnu.org

  What about platforms that don't have sigprocmask, but do have SIGINT?
  Don't we want to block SIGINT on those platforms?

 Do they have threads

 They might.  (The only way I've succeeded to have a working Guile on
 Windows was to disable threads, but I hope that bug will be fixed one
 day.)

 and how does one block SIGINT on those platforms?

 With a call to 'signal', I guess.

I'm guessing that won't work here, we'll need something else.
The issue is we need the threads that guile starts
to have these signals blocked. Then after guile init
returns we unblock the signals.



Re: [RFC] Block all async signals used by gdb when initializing Guile

2015-08-29 Thread Eli Zaretskii
 Date: Sat, 29 Aug 2015 13:39:55 -0700
 From: Doug Evans xdj...@gmail.com
 Cc: gdb-patc...@sourceware.org gdb-patc...@sourceware.org, guile-devel 
 guile-devel@gnu.org
 
 On Sat, Aug 29, 2015 at 1:16 PM, Eli Zaretskii e...@gnu.org wrote:
  Date: Sat, 29 Aug 2015 12:20:24 -0700
  From: Doug Evans xdj...@gmail.com
  Cc: gdb-patc...@sourceware.org gdb-patc...@sourceware.org, guile-devel 
  guile-devel@gnu.org
 
   What about platforms that don't have sigprocmask, but do have SIGINT?
   Don't we want to block SIGINT on those platforms?
 
  Do they have threads
 
  They might.  (The only way I've succeeded to have a working Guile on
  Windows was to disable threads, but I hope that bug will be fixed one
  day.)
 
  and how does one block SIGINT on those platforms?
 
  With a call to 'signal', I guess.
 
 I'm guessing that won't work here, we'll need something else.

I don't understand why.  Can you explain?  Maybe I'm missing
something.

 The issue is we need the threads that guile starts
 to have these signals blocked. Then after guile init
 returns we unblock the signals.

Inhibit SIGINT ech time before calling Guile and restore it after
Guile returns.  Wouldn't that do what you want?



Re: [RFC] Block all async signals used by gdb when initializing Guile

2015-08-29 Thread Eli Zaretskii
 Date: Sat, 29 Aug 2015 23:04:02 +0200 (CEST)
 From: Mark Kettenis mark.kette...@xs4all.nl
 CC: e...@gnu.org, gdb-patc...@sourceware.org, guile-devel@gnu.org
 
 I suppose blocking these in the threads that guile starts is necessary
 because that is the only way to guarantee that those signals will be
 delivered to the main gdb thread on POSIX systems.
 
 On Windows you probably need to do something completely different.

I might be missing something, because I don't see why.