GIL in the new glossary

[Luis P Caamano]

jjl at pobox.com (John J. Lee) wrote in message news:<87oewzyv81.fsf at pobox.com>...
> "Luis P Caamano" <lpc at racemi.com> writes:
> [...]
> > application in any other language, ever.  As it is right
> > now, if I need to run a server app on a big MP machine
> > and I need to scale accordingly, I have two choices:
> > 
> > a) play with IPC again (as in if we were back in
> >    in the 80s before pthreads) to have separate interpreters
> >    per processor or 
> [...]
> 
> Sounds like a great idea to me.  :-)

Not if you need several hundred threads in your app.

> 
> Did you get the earlier references to POSH?

No, I didn't.

> 
> http://poshmodule.sourceforge.net/posh/html/
> 

I just read the docs.  It's pretty cool.  Thanks for
the pointer as it is something we could definitely use
right away.

However, although this is a great solution for some
cases, it's not a solution for all cases.
There's a table at the end of the doc that shows
a performance comparison between using python
threads and multiple processes, clearly showing how
much faster the posh implementation is when using
more than one processor.  It would be really nice to
see how it would compare to the same app written in
C running on an OS with an MxN pthread library.  :-)
I'd expect the results to prove my point.

> 
> People's attitude to threading does often remind me of the dogmatic
> attitude to static typing, that regards all other solutions as being
> somehow intrinsically second-best...

Some python developers' attitude toward threads remind
me of Linus' initial argument against POSIX threads in
Linux: "Just use clone! POSIX is stupid"  Leading to
incompatible signal behavior in Linux until recently
with the introduction of the NPTL after almost 10 years.
 
There are many applications where threads are definitely
better than multi-processes, IPC, and shared memory.  In
some cases, threads are the only way, e.g., if the app
requires thousands of threads.  Or do you think threads
came to be just because they were cool?  

I agree that using mp, IPC, and shared memory is
a way to get around the GIL, but just because python
doesn't have free threading doesn't mean threading
is bad.  Having to use shared memory and multiple
processes is a step backwards and one BIG reason,
if not the biggest, that holds some people back from
using python for large scale apps.  It is a tough
problem to solve, I agree and I understand why it
hasn't been solved and why it will take a while to
tackle it.  However, it will have to be solved eventually
and any argument saying it doesn't need a solution is
just like trying to cover then sun with a thumb.

The GIL is a convenience that hurts only a few.  When
that few grows to a critical number, the GIL will
disappear.  Until then though ...

--
lpc