threading support in python

[Sandra-24]

> 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