race in pthread_suspend_np

I finally found some time to play with ngpt (2.0.1 this time) and
libgc (6.1 by now).

First of all: thanks for adding pthread_getsp_np. I had a similar
patch (named pthread_get_stackptr_np), but dropped it after being
hinted at pthread_getcontext_np. But not having to decode the context
myself is of course so much better (and more portable across
architectures).

As Boehm and I said earlier, there seems to be a possible race in
pth_suspend on SMP (or MAXNATIVETHREADS > 1). And the test-program for
libgc maages to trigger this situation. If I set MAXNATIVETHREADS to 2
or 4, the program stops 2 times out of 5 because pthread_suspend_np
returns ESRCH. I estimate this as being in 0.01% of the calls, but I
haven't measured them.

First the state of the thread is checked and the appropriate queue
selected, then the thread is removed fron the selected queue. However,
between those operations, another native thread could change the
thread-state (by starting to run it, for example) and the queue. This
situation is recognised and ESRCH is returned. However, instead I
think the scheduler (and probably other functions) should block when
attempting to change the thread-state, and possibly the
queue. Alternatively, the interface could be defined to return EAGAIN
(that sound more like what is meant in this case), with a nice comment
in the header-file.

As I don't nearly know anough about the code to add the blocking
myself (I could lock the thread and/or the queues, but what is the
relationship betweeen them?), I can't provide you with a patch.

Also, a similar race seems to exist when reading using pth_read. The
last comment in pth_read_ev states at that time 1 read is
save. However, I think that one read could be consumed by another
native thread/process, effectively blocking this native thread untill
another byte gets available. But I'm not very sure: I haven't seen the
behaviour and the scheduling-problems with regard to poll-events up
till now clouded this area anyhow.

Bye,
        Marijn