Re: Merge of nickrob-async-20060513 to mainline?

Nick Roberts
2006-10-08T03:46:27Z

[-- 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 --]