If you have ideas about what we need to do to threads, put them here....

Provide a way of specifying the *total* amount of shared memory to have
available rather than the amount per processor.

Fix mprotect() on the KSR by using mmap of /dev/null.  Depends on this FPR
being fixed....
>   FPR Pri Rel    Fixed  Description
>   =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>   10262 M* 1.1.4         vm_protect() function not working

fix sgi shared memory...

Eliminate ugly stack alignment stuff in sched_utils.c by doing machine
specific subroutine instead.

Fix the memory leak problem with names.  This memory leak was introduced
because monitoring saves pointers to names in some events (cthread_fork,
mutex_alloc, condition_alloc, etc.).  Because events are not posted
immediately (I.E. they hang around in buffers until the local monitor
collects them for writing to a file), there is a chance of those pointers
becoming invalid before monitoring writes the stuff to a file.  Encountering
this problem is not unlikely because often the first thing one does after
creating an entity (thread, mutex or condition) is to use the *_set_name()
calls to give it a name.  If *_set_name() uses free() to release the memory of
the old name, this invalidates the pointer that monitoring has and can trigger
the problem.  Our temporary hack is to comment out the call to free() in the
*_set_name() routines.  This means that old name pointers remain valid
forever, at the cost of a permanent memory leak...  The *proper* solution to
this problem, fixing monitoring so that it doesn't depend upon the validity of
memory that it doesn't control, is a complicated fix.  Until it is done, we
pretty much have to tolerate this memory leak.

test