[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: -DNO_THREADS, select(), signals



Ed Carp wrote:
> 
> > 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?

Are you actually using -DNO_THREADS?