Messages in this thread |  | | From | "David Schwartz" <> | Subject | RE: thread rant | Date | Mon, 4 Sep 2000 21:49:04 -0700 |
| |
> I've heard comments from Alan, and others in the past bashing > threads, and I can understand the "threads are for people who > can't write state machines" comments I've heard, but what other > ways are there of accomplishing the goals that threads solve in > an acceptable manner that gives good performance without coding > complexity?
That's a nonsensical complaint anyway, since you need to use state machines with threads. When there's work to be done, you hand it to a thread. That thread needs to know what state the object it's working on was in. When that thread is finished working, that object is in some other state.
The reason you need threads is because you may have 12,000 state machines and 3 of them may need to be worked on at the same time. You may not know ahead of time whether the needed work is CPU intensive, I/O intensive, or neither.
> This is all just curiosity. I've considered trying some thread > programming, but if it is as stupid as it sounds, I'd rather > learn the "right" way of writing code that would ordinarily be > done with threads, etc.. Right now, I'm using fork() all over > the place and don't much care how much waste it is... I'd like > to though.
Fork is good if you really need a whole process. It's also good if you're doing something potentially risky and can't afford to the process that is forking fail. It makes life miserable, however, if you need tight communication with the forked process.
There are plenty of things I don't like about pthreads. But pthreads is not threads. A lot of the ugliness in pthreads was to allow operating systems that couldn't do threads right to claim to 'fully support' threading.
One major problem with a big 'poll loop' is that you're vulnerable to ambush. A sudden page fault from a slow disk (or worse, NFS mount *shudder*) and your entire process screeches to a halt. Obviously, one process per connection/task is out of the question. Threads give you a very satisfying in-between point.
DS
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |