Re: linux native async mode support

[Nick Roberts <nickrob at snap dot net dot nz>]

 > This patch adds linux native async mode support.

Wow!  This is an awesome patch especially as your previous changes seem to be
for different parts of Gdb.  I think my patch only really worked if only one
SIGCHLD signal came in for each round trip in the event loop.  I was starting
to see that that the signal handler shouldn't be wrapped around select and that
I would need to queue signals but I never began to understand all the waitpids
in linux_nat_wait or how to get back to the event loop when all the SIGCHLD
signals had been processed.

I have some initial comments but bear in mind it's from a position of lesser
understanding.  I can see that I really need to up my game a bit!

It seems unfortunate that you had to move async_file_handler into linux_nat.c
as much of this seems generic and will presumably make it harder to port the
async mode to other platforms.  I put it in inf-ptrace.c (*) which creates
problems if the target doesn't actually support async mode.  More recently I
thought maybe not setting t->to_async_mask_value to 1 in inf_ptrace_target
might solve that.

(*) I copied this from Apple whose handler was in macosx-nat-inferior.c
but their build is only for one architecture (maybe two now but source
appears to be no longer available from their repository)

---

+  /* SIGCHLD handler for async mode.  */
+  async_action.sa_handler = async_sigchld_handler;
+  sigemptyset (&async_action.sa_mask);
+  async_action.sa_flags = SA_RESTART;
+  sigaddset (&async_action.sa_mask, SIGCHLD);

I'm not sure that last line is necessary (I had it in my patch, I know) as the
libc manual says:

     When a handler function is invoked on a signal, that signal is
  automatically blocked (in addition to any other signals that are already
  in the process's signal mask) during the time the handler is running.

---

Daniel talks about async mode being the default but I don't really understand
this.  In order for Gdb to be able to accept input while the inferior is
running and possibly accepting it's own input, seems to require separate
terminals.  This isn't a problem for a front end but, in general, will be
when Gdb is run from the command line.

-- 
Nick                                           http://www.inet.net.nz/~nickrob