Re: -DNO_THREADS, select(), signals

[Richard Krukar <krukar@ectopia.com>]

Is anyone familiar with how apache manages message
queues?  I know that a number of process are spawned, each
of which handles a predetermined number of requests before
dying.  I think we've got some apache internals gurus lurking
on this list who know the connection management details.

	I think the NT port will really blow without thread
pools.  Under NT, a thread is damn near as heavy as a
process.  Process start-up time under NT is worse.  execs
can make an NT application really crawl. Hence, people use
thread pools.

	Anyway, I don't see why the -DNO_THREADS option
can't be retained within a threaded I/O management system.
Just service requests immediately instead of dispatching
threads to do it.  Something like:

/* in a .h file
#ifdef NO_THREADS
#define MAX_THREADS 0
#endif

int dispatch_thread( void *routine ) {
   if( thread available ) {
      // give work to a thread
      return;
   }
   if( MAX_THREADS ) {  // using threads, none available
       /* issue "can't do it" response or
       leave request on queue for next time */
       return;
   }
   (*routine)(); // no threads, just do it
   return;
}

	Will do the trick.  This assumes a return mechanism
such as results and errors being returned to the queue as a
different message type.  Also, all the NO_THREADS ifdefs
can be localized to a small set of routines.

	The thread libraries can be either be compiled in
such that mutex calls become time consuming no-ops or
some energetic soul can write a "no_pthread.h" file which
directly no-ops the function defs.

	...richard