> You seem to be confused about the nature of multiple-process > programming. > > If you're on a modern Unix/Linux platform and you have static read-only > data, you can just read it in before forking and it'll be shared > between the processes..
Not familiar with *nix programming, but I'll take your word on it. > If it's read/write data or you're not on a Unix platform, you can use > shared memory to shared it between many processes. I know how shared memory works, it's the last resort in my opinion. > Threads are way overused in modern multiexecution programming. The <snip> > It used to run on windows with multiple processes. If it really won't > now, use an older version or contribute a fix. First of all I'm not in control of spawning processes or threads. Apache does that, and apache has no MPM for windows that uses more than 1 process. Secondly "Superior" is definately a matter of opinion. Let's see how you would define superior. 1) Port (a nicer word for rewrite) the worker MPM from *nix to Windows. 2) Alternately switch to running Linux servers (which have their plusses) but about which I know nothing. I've been using Windows since I was 10 years old, I'm confident in my ability to build, secure, and maintain a Windows server. I don't think anyone would recommend me to run Linux servers with very little in the way of Linux experience. 3) Rewrite my codebase to use some form of shared memory. This would be a terrible nightmare that would take at least a month of development time and a lot of heavy rewriting. It would be very difficult, but I'll grant that it may work if done properly with only small performance losses. Sounds like a deal. I would find an easier time, I think, porting mod_python to .net and leaving that GIL behind forever. Thankfully, I'm not considering such drastic measures - yet. Why on earth would I want to do all of that work? Just because you want to keep this evil thing called a GIL? My suggestion is in python 3 ditch the ref counting, use a real garbage collector, and make that GIL walk the plank. I have my doubts that it would happen, but that's fine, the future of python is in things like IronPython and PyPy. CPython's days are numbered. If there was a mod_dotnet I wouldn't be using CPython anymore. > Now, the GIL is independent of this; if you really need threading in > your situation (you share almost everything and have hugely complex > data structures that are difficult to maintain in shm) then you're > still going to run into GIL serialization. If you're doing a lot of > work in native code extensions this may not actually be a big > performance hit, if not it can be pretty bad. Actually, I'm not sure I understand you correctly. You're saying that in an environment like apache (with 250 threads or so) and my hugely complex shared data structures, that the GIL is going to cause a huge performance hit? So even if I do manage to find my way around in the Linux world, and I upgrade my memory, I'm still going to be paying for that darned GIL? Will the madness never end? -Sandra -- http://mail.python.org/mailman/listinfo/python-list