This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: async patch (no. 4)


On Mon, Jun 18, 2007 at 05:00:20PM +1200, Nick Roberts wrote:
> Sure, but to be fair I think this is the first time you have asked them.

Sure.  Like I said, the patch is hard to review.  I think that each of
the bits I asked a question about is, logically, a separate change to
GDB.  More or less.

> 1) what does async_signal_hook do
> 
>    Firstly this patch only currently works for Linux.  That is because I don't
>    know enough about other OSes and ISTR that you said others could extend
>    easily it to them later.  For Linux, async_signal_hook is initialised to
>    linux_nat_signal_hook in _initialize_linux_nat.  It is called (with
>    different arguments) immediately before and after calls to select (or poll,
>    if appropriate) and only if gdb is invoked with --async (event_loop_p != 0).
> 
>    On the first call, linux_nat_signal_hook sets up a handler,
>    async_sigchld_handler, for SIGCHLD, that writes the return value of waitpid
>    to the file descriptor that linux_nat_fetch_event reads from.
>    linux_nat_fetch_event is called instead of my_waitpid with an asynchronous
>    target in linux_nat_wait.  On the second call linux_nat_signal_hook
>    restores the old signal mask.
> 
> 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.

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.

-- 
Daniel Jacobowitz
CodeSourcery


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]