RE: -DNO_THREADS, select(), signals

["Howard Chu" <hyc@highlandsun.com>]

In every large project that I have worked on in the past 8 years,
all of the most annoying and difficult to trace bugs have eventually
been tracked down to a buggy vendor-supplied threads implementation.
My knee-jerk reaction to your proposal is "threads are evil." Most
often the uses of threads that I've encountered have been trivial
jobs that would be implemented more efficiently using timers and
async I/O. In general, it's safer to spawn multiple processes with
a shared memory region - your sharing is done explicitly, and nothing
you don't want shared can be accidentally corrupted. As opposed to a
threads environment where even things you're not sure about need to
be protected by mutex, just in case....

With that said, I recognize that I'm in a tiny minority on
this viewpoint, so I'll shut up.

> As noted a couple in a couple of different threads, slapd
> would benefit greatly from threaded I/O management system
> (It currently uses a select-based I/O management system).
> The integration of the thread-based processing system
> and the select-based I/O system has been problematic.
> Though we have worked out most of the problems, new issues
> (multiple listeners, TLS, NT, thread pools) will cause
> further stress to be added to this design mismatch.
> 
> I would like to reimplement our select-based connection
> management to use threaded implementation (using per-socket
> threads).  This will eliminate the dependency upon select(),
> signals, and greatly simplify I/O and operation thread
> management.
> 
> However, the expense is -DNO_THREADS.
> 
> Any heartburn if -DNO_THREADS support is dropped?
>