Tim Peters wrote: > >... > > You can't get massive scalability using OS threads, unless the OS is an > oddball specifically designed for that. Worming around the bloat of Windows > and Linux (etc) OS threads is Stackless Python's natural domain (simulated > threads). The catch, of course, is they that don't run in parallel! Or > maybe by "massive" you mean a few dozen? I worked in the "massively > parallel supercomputer" biz, so I'm thinking more on the order of a few > thousands of dozens. I bet you're not. I am thinking about getting as many threads as there are processors to run truly in parallel. > > ... > > Why do people use mod_python, fcgi, mod_snake, mod_php and all of those > > other things instead of pure CGI? > > Beats me why people bother with web programming at all <wink>. Yeah, that describes alot of us in the Python world. I think that explains the emergence of PHP. <0.1 wink> Even Zope is really an OO database that made a few concessions to the fashionable object delivery mechanisms of the day. >... > IIRC, Greg's fabled free-threading version of Python took a speed hit of > about a factor of 2 (for a program using only 1 thread, compared to that > same program without the free-threading patches). The Perl guys considered this unacceptable and I can kind of see their point. You have two processors but you get roughly the same performance as one? >.. > Well, the idea that threads don't share information is foreign to every > intense belief about the world *I've* ever been paid to adopt <wink>, and > I'm not enough of a Windows geek to believe "threads are always the answer" > even so. A pool of worker processes using OS-specific IPC as needed works > great in my real-life experience, and if information sharing is rare, works > especially great because it's not *fighting* the OS and C libraries tooth > and nail. I really don't see this as fighting anything. There are thousands of C-coded libraries out there that can be used in multiple C threads without sharing information between them. Some of those libraries happen to be interpreters (e.g. PHP, VBScript) that are much more popular in embedded server applications than Python. Maybe just a coincidence but I think that there are a host of reasons and this may be one of them. > What of your hypothetical user earlier, who "isn't going to be happy with > the price of ... using IPC for information sharing either"? That is, in > what sense do isolated threads leave her happy about her information sharing > needs? You share information (if at all) through the threaded host. The host handles serialization of access to shared information. E.g. Apache wants to tell you about the cookies that go with a request. That shouldn't be copied from one process to another. It should be "just available." Sendmail wants to tell you about the message contents of the message you are filtering. Your SQL database with Python stored procedures has huge shared state but the Python procedures would never share state themselves. Your video game has a set of objects available representing physical objects. Python interpreters would never talk to each other about them directly -- they would always move the objects around the objectspace and the engine routes the information between the interpreters. There is no "IPC" between Python programs. All communication is between the host environment and the interpreter. If the host chooses to share the information with other interpreters then it is the host's job to manage serialization and it is the host's fault if performance lags. Anyhow, these servers exist and use threads for parallel processing. Either we play nicely with them as a good citizen or you don't. We bend over backwards to be a good embedded citizen on many other issues. We could argue that Apache 2 made a wrong turn in moving from processes towards threads but I think that's a little like announcing the falling of the tree in the wood. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook
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