Live data from Hacker News

Python 3.0 Released

python.org

61–63 of 63 posts

Re: Python 3.0 Released

#61
post #60
post #59

Earlier quoted context omitted.

They are not the same thing. Threads share address space and processes don't and that's a crucial difference.

I said same thing with different flavors. Literally, they are both represented by the same data structure in the kernel. The salient point of the discussion - cost of forking a process versus cost of spawning a thread - is the same. They require different styles of programming, but I was responding to your point on cost. If you ever need to reason about scheduling in the Linux kernel, then you need to understand this…

I understand I was less than clear on my concern about the cost of starting a process versus starting a thread, but that was not all of my point. Besides the convenient shared memory space, threads also should take a little less to start because they don't need a new memory context. In long running threads, this is not much of a problem but if you decide to start a lot of threads, that could make a difference. I don't know if the Linux kernel makes a big deal out of this but I am sure that, as programs get more threaded, the cost of starting a thread will approach the theoretical minimum thanks to our skillful kernel developer friends.

I am not familiar with current (less than 10 year-old) processor architectures, but, back when I was familiar with that stuff, switching context between threads of the same process was a lot less costly than switching between different processes because the memory context is the same and set-up and tear-down was a somewhat costly operation. As processors start getting more cores, it also allows schedulers to keep threads of the same process to the same cores, reducing context-switch overhead (or to power-down less used cores to conserve energy).

If I had a very good threading/multi-core support, I would probably go with Solaris on a 64-thread T2 SPARC thingie, not Linux on 6-thread x86. And that's a good reason for Sun to invest some money on helping convince Guido the GIL is bad and will become worse with time. Because Intel will probably catch up.

Re: Python 3.0 Released

#62
post #18

Earlier quoted context omitted.

I run a stable CherryPy app on 2.6 . It was a bit painful for about a week after 2.6 came out, but became stable pretty fast. There are a whole lot of possibilities for a "webapp stack" in python. What are you running your sites on top of?

The Python LDAP and psycopg2 libraries are my biggest culprits. My point is not that it's impossible to run 2.6; but setting it up requires a level of sophistication with Python/*nix that I can't put on the shoulders of my organization, yet. If I were working with a couple of smart hackers, this would be a non-issue. But my feeling is my organization is like a lot of others, where anything that's not a tagged, stable…

Ahh, yeah it does require a good bit of familiarity with both python and *nix environments.

I'm a lone guy, managing my own servers, with complete control over their environments. That's quite a bit different than a business environment, corporate or not.

Post reply on HN