Mike Meyer wrote: > Bryan Olson writes: > >>Mike Meyer wrote: >> > The rule I follow in choosing my tools is "Use the least complex tool >> > that will get the job done." >> >>Even if a more complex tool could do the job better? > > In that case, the simpler model isn't necessarily getting the job > done. I purposely didn't refine the word "job" just so this would be > the case.
I didn't ask about any particular case. You stated a general rule you follow, and I think that rule is nuts. >>Now I've gotten off-topic. Threads are winning, and the industry >>is going to multiple processors even for PC-class machines. >>Might as well learn to use that power. > > I own too many orphans to ever confuse popularity with technical > superiority. The issue here is whether to confuse reality with what one might wish reality to be. > I've learned how to use threads, and done some > non-trivial thread proramming, and hope to never repeat that > experience. It was the second most difficult programming task I've > ever attempted(*). Great -- lets see it! Can you point out what parts were so hard? How would you have solved the same problems without threads? > As I said above, the real problem isn't threads per > se, it's that the model for programming them in popular languages is > still primitive. So far, to achieve the non-repitition goal, I've used > async I/O, restricted my use of real threads in popular languages to > trivial cases, and started using servers so someone else gets tod eal > with these issues. Then maybe we should listen to those other people. Is there a successful single-line-of-execution async-I/O based server that provides a service as sophisticated as the modern relational- database engines? Why do you think that is? -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
