pthreads

[Robert Collins]

Any objections if I do a <sarcastic>little bit</sarcastic> of
housekeeping in pthread.h thread.cc & thread.h ? There's a few serious
issues there with the type definitions (which I blindly followed for
pthread_cond* - making it worse :[).

I believe I can make it leaner and meaner, and more compatible/easy to
build on in future....

Fortunately I believe this can be done without breaking existing
compiled programs (I'll especially test for this).

As a side effect it will make some of it 64 bit clean.

Rob

Details for those who care:
At the moment we have an number of fixed size arrays of multi-thread
items, that we store a int index into for some of the pthread types, and
structs in userspace for the rest. The problem with structs is that we
cannot change their size as we write more functionality in. (I went to
do the patch for Norman Vine's question and realised I'd break the ABI).

Fortunately all the useable structs are 4 bytes long, as are all the
index's. All those types should be pointers to objects created in
cygwin1.dll, not userland variables.

The housekeeping includes two things:
* change the typedefs to be pointers so we can work more freely in the
future,
* and rewrite the guts of thread.cc & thread.h to allocate new objects
on the stack and store the pointer rather than an index. This also
removes the overhead of walking the list for user space requests, and
simplifies the code.

I've done a check on the typedef changes in pthread.h, and all my
precompiled thread test programs still work fine* - so I'm confident of
the success of the change.

* With the expected exception of pthread_cond* variable access. But
that's not even in a snapshot yet, so I don't consider it a problem.