Greg Ewing wrote:
On 12/08/10 18:44, ghazel@gmail.com wrote:
why not just use threads?
One reason not to use threads is that they're fairly heavyweight. They use OS resources, and each one needs its own C stack that has to be big enough for everything it might want to do. Switching between threads can be slow, too.
In an application that requires thousands of small, cooperating processes, threads are not a good solution. And applications like that do exist -- discrete-event simulation is one example.
Sure, and those use Stackless to solve the problem, which IMHO provides a much more Pythonic approach to these things. Stackless also works across C function calls, a detail which will become more important as we think about JIT compilers for Python and which is not something we want the average Python programmer to have to worry about. Stackless hides all these details from the Python programmer and works well on the platforms that it supports. So if we really want such functionality in general Python (which I'm not convinced of, but that may be just me), then I'd suggest to look at an existing and proven approach first. The techniques used by Stackless to achieve this are nasty, but then Python also ships with ctypes which relies on similar nasty techniques (hidden away in libffi), so I guess the barrier for entry is lower nowadays than it was a few years ago. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 13 2010)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/