From: Nick Roberts <nickrob@snap.net.nz>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb@sources.redhat.com
Subject: Re: Merge of nickrob-async-20060513 to mainline?
Date: Sun, 08 Oct 2006 03:46:00 -0000 [thread overview]
Message-ID: <17704.29662.459220.234430@kahikatea.snap.net.nz> (raw)
In-Reply-To: <20061006032420.GA22658@nevyn.them.org>
[-- Attachment #1: message body and .signature --]
[-- Type: text/plain, Size: 1807 bytes --]
> > Yes I think so. I don't quite follow the explanation of pselect in the
> > manpage but I think you're saying that the signal handler for SIGCHLD will
> > run even when GDB is already in select, and can get GDB's attention by
> > writing to a pipe with a file descriptor that select is watching.
>
> Exactly. Actually, getting the signal may also knock GDB out of the
> select syscall; that depends on whether the "SA_RESTART" flag is used.
> But you want to rely on the pipe, as there are fewer corner cases.
I've tried to do this now. This approach has the added benefit that the tests
checkpoint.exp, multi-forks.exp work now. I've also resolved fails in
attach.exp and jump.exp.
Ignoring sigstep.exp again, I now get:
=== gdb Summary ===
# of expected passes 10789
# of unexpected failures 58
# of unexpected successes 1
# of expected failures 42
# of unknown successes 3
# of known failures 70
# of unresolved testcases 2
# of untested testcases 5
# of unsupported tests 4
/home/nickrob/src4/gdb/testsuite/../../gdb/gdb version 6.5.50.20061006-cvs --async
Fails still exist for server-run.exp, print-threads.exp and staticthreads.exp.
define.exp fails with the script nextwhere. Asynchronous operation means that
it tries to do `where' before 'next' has finished. Perhaps scripts should be
forced to run synchronously.
It's almost there now although I still need to tidy it up e.g move waitpid out
of event-loop.c and put declarations in header files rather than use externs.
I would like to commit these changes shortly after the next release so that
there is a full six months to iron out any problems they might cause.
I attach the compressed diff below for general inspection.
--
Nick http://www.inet.net.nz/~nickrob
[-- Attachment #2: Asynchronous operation using signal handler --]
[-- Type: application/octet-stream, Size: 43519 bytes --]
next prev parent reply other threads:[~2006-10-08 3:46 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-30 2:27 Nick Roberts
2006-08-30 2:33 ` Daniel Jacobowitz
2006-08-30 3:21 ` Nick Roberts
2006-08-30 4:01 ` Daniel Jacobowitz
2006-08-30 12:31 ` Eli Zaretskii
2006-08-30 21:34 ` Nick Roberts
2006-08-30 21:43 ` Daniel Jacobowitz
2006-08-30 23:45 ` Nick Roberts
2006-09-26 8:41 ` Nick Roberts
2006-09-26 12:38 ` Daniel Jacobowitz
2006-09-26 22:12 ` Nick Roberts
2006-09-26 22:24 ` Daniel Jacobowitz
2006-09-26 23:40 ` Nick Roberts
2006-09-29 1:50 ` Nick Roberts
2006-10-06 0:53 ` Nick Roberts
2006-10-06 1:26 ` Daniel Jacobowitz
2006-10-06 2:13 ` Nick Roberts
2006-10-06 3:24 ` Daniel Jacobowitz
2006-10-08 3:46 ` Nick Roberts [this message]
2006-10-09 18:00 ` async implies sync, was " Michael Snyder
2006-10-09 20:28 ` async implies sync Nick Roberts
2006-08-31 21:03 ` Merge of nickrob-async-20060513 to mainline? Mark Kettenis
2006-08-31 21:49 ` Nick Roberts
2006-08-31 22:29 ` Daniel Jacobowitz
2006-08-31 22:40 ` Nick Roberts
2006-08-31 22:53 ` Michael Snyder
2006-08-31 23:33 ` Nick Roberts
2006-08-31 23:37 ` Daniel Jacobowitz
2006-08-31 23:59 ` Jim Ingham
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17704.29662.459220.234430@kahikatea.snap.net.nz \
--to=nickrob@snap.net.nz \
--cc=drow@false.org \
--cc=gdb@sources.redhat.com \
/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