Re: [patch] New thread test to exercise Daniel's Patch

[Jeff Johnston <jjohnstn at redhat dot com>]

Daniel Jacobowitz wrote:
> On Fri, Mar 26, 2004 at 04:13:18PM -0500, Jeff Johnston wrote:
>
> > See the attached test.  There was some stuff in pthreads.exp about Crtl-C 
> > and alpha-*-osf*.  Do I need to account for this platform?
>
>
> Well, it's still supported, but I have no idea whether the bit in that
> test is necessary - or what it's supposed to accomplish.  So let's
> ignore it.
>
>
> > +# This only works with native configurations
> > +if ![isnative] then {
> > +    return
> > +}
>
>
> This shouldn't be necessary.

Ok.

> > +set testfile "manythreads"
> > +set srcfile ${testfile}.c
> > +set binfile ${objdir}/${subdir}/${testfile}
> > +if {[gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug libs=-lpthread}] != ""} {
>
>
> See gdb_compile_pthreads.

Will do.

> > +send_gdb "set print sevenbit-strings\n" ; gdb_expect -re "$gdb_prompt $"
>
>
> gdb_test "set print sevenbit-strings" ""

Ok.

> > +send_gdb "continue\n"
> > +gdb_expect {
>
>
> Everywhere you're using gdb_expect, please use gdb_test_multiple
> instead.  For the "after" tests, you can use gdb_test_multiple with
> "" as the first argument.

I tried this initially but I kept getting "Error: internal buffer is full".  I 
tried lowering the "after" time which is why it ended up 100 below but that 
didn't solve the problem.  Any suggestions on how to avoid the "full_buffer" error.

> > +# Send a Ctrl-C and verify that we can do info threads and continue
> > +after 100 {send_gdb "\003"}
>
>
> Is 100 ms enough to be interesting?

It still kicks off a fair number of threads that have started/exited, but I can 
make this bigger.

-- Jeff J.