Re: -DNO_THREADS, select(), signals

["Ed Carp" <erc@pobox.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.

I agree.  Please DO NOT drop support for NO_THREADS!!  Threads is one of
those politically-correct things, like Java, that can be served better by
existing processes.  Why is it that people always have to try and make their
mark by inventing something "better" that usually turns out to be buggier,
more complex, and more of a pain-in-the-butt than what came before?
--
"A friend is someone who won't give up until he finds you, and brings you
home".  -- Robert Fraser

Ed Carp, N7EKG - erc@pobox.com - 9403672744@mobile.att.net for URGENT
messages only!
Web: http://www.pobox.com/~erc