setre?id() since new systems apparently hang on that call when the IDs
are already what you want.  Further, use a single mutex to protect both
do_setuid() and do_seteuid().

The symptoms:
When you connect to the BBS, the user prompt would repeat quickly three
times then drop carrier on you.  Nothing you entered ever showed up.
--OR--
You seem to connect to the BBS, but you never see any output.

This was only easily reproduced when starting the system as a non-root
user.

This has been confirmed on FC3, FC4, and Debian etch.


The cause:
output_thread or input_thread called thread_up() which called do_seteuid()
which hung in setregid().  Since do_seteuid() is holding a mutex at this
point, when the other *put_thread calls thread_up(), it waits forever for
the mutex.  If output_thread starts first, this results in getchr()
returning ^C every time it's called since input_thread_running is false.


Question for DigitalMan:
Should output_thread/input_thread post a semaphore when they're up to prevent
SMP systems from getting far enough into answer() to call IO stuff before the
corresponding thread is running?  A timed semaphore wait in main.cpp then
could be used (you wouldn't want to block forever in case this happens again).