On Saturday 13 December 2003 09:01, Keith Dart wrote: ... > Python. Comments such as "I don't do threads in Python", "threads suck", > and "avoid threads" were heard. That is typical of the kinds of That's how my own recommendations on the subject invariably run (whether the language in use is Python or not) -- see for example http://www.strakt.com/docs/os03_threads_interrupt.pdf or the classic http://www.softpanorama.org/People/Ousterhout/Threads/ . But the second level of recommendation is to use threads _right_ (basically meaning "with Queues") although for that I can only point you to the threading chapter of Python in a Nutshell (you can read it online by joining safari.oreilly.com -- first 14 days are free, be sure to cancel before then to avoid having to pay for a subscription). > I have read Sam Rushing's treatise on threads and co-routines, and have > used his "medusa" http server framwork. I like that "reactor model" > myself. It works well for programs that utilize a lot of I/O. I have If you like the Reactor pattern you'll probably love Twisted Matrix, http://www.twistedmatrix.com/ . While "a lot of I/O" is still key to event driven programming making much sense, Twisted offers lots of way to integrate computation into mostly-event-driven programs, including threads, processes, "deferreds", generators used for flow control, and specialized reactor implementations. > One other method that I use is to use forked processes as if they were > threads. That combined with a third-party module that exposes sysV IPC > to Python provides the same benefits as threads but without the > problems. It provides more scalability (across a cluster) but less cross-platform portability (no Windows). Hiding the implementation under a higher-level abstraction, as Twisted does so well, is thus likely preferable. Alex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4