async patch (no. 4)

Nick Roberts nickrob@snap.net.nz
Mon Jun 18 21:48:00 GMT 2007


 > > I'll try to answer the other questions in due course, but I'd like to hear
 > > if you think I'm making sense trying to answer this one first.
 > 
 > Yes, that makes sense - thank you, and this gives me a sense of making
 > progress on the async patch :-)
 > 
 > It does explain what the hook is for, although actually the hook is
 > the wrong approach.  If this belongs to the native target, then it
 > should be target_async_signal_hook (1) and go through the target
 > vector.  On the other hand, if the remote target is going to want to
 > use the same technique on GNU/Linux (i.e. if it depends on the host)
 > then maybe it belongs somewhere else and not as a hook at all.  Either
 > utils.c or posix-hdep.c depending how different it is going to be on
 > multiple platforms.

Perhaps I'll start with the native target because it looks easier and I
think I understand that.

You mean define a method t->to_async_signal_hook and use it like this:

#define	target_async_signal_hook(args) \
 (*current_target.to_async_signal_hook) (args)

Right?

 > More broadly, we have a couple of different ways for providing
 > host-specific and target-specific code so a new global function
 > pointer should be avoided.

2) Why does async behavior change where we need to claim the terminal?

I don't think it does generally change _where_ we need to claim it but _how_ we
do.  I think the idea is just to add and remove the file handler,
async_file_handler, which invokes inferior_event_handler when gdb take/gives
up the terminal.

3) Are the quit_flag changes still necessary now that we've done some work on
QUIT? 

They have already been added as part of the patch that Fred Fish committed.

4) Why don't the infrun changes break thread handling all over the place?

I'm afraid that the changes in infrun.c are voodoo that I've copied from Apple.
This is one file that I don't think I'll understand for a long time, if at
all.  My approach has been empirical which probably reveals my scientific
background where it is highly rated (but computer scientists just don't
seem to get it!).

However, I can say that thread handling improved when I used the variable
gdb_file_event in async_sigchld_handler:

static void
async_sigchld_handler (int signo)
{
  int msg[2];
  int status, options;

  if (gdb_file_event)
    options = __WCLONE | WNOHANG;
  else
    options = __WALL | WNOHANG;

  msg[0] = waitpid (-1, &status, options);

  if (msg[0] > 0)
    {
      msg[1] = status;
      write (gdb_status[1], msg, 2*sizeof (int));
      gdb_file_event = 1;
    }
}

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



More information about the Gdb-patches mailing list