On Nov 4, 9:38 am, sturlamolden <[EMAIL PROTECTED]> wrote:
> First let me say that there are several solutions to the "multicore" > problem. Multiple independendent interpreters embedded in a process is > one possibility, but not the only.'' No one is disagrees there. However, motivation of this thread has been to make people here consider that it's much more preferable for CPython have has few restrictions as possible with how it's used. I think many people here assume that python is the showcase item in industrial and commercial use, but it's generally just one of many pieces of machinery that serve the app's function (so "the tail can't wag the dog" when it comes to app design). Some people in this thread have made comments such as "make your app run in python" or "change your app requirements" but in the world of production schedules and making sure payroll is met, those options just can't happen. People in the scientific and academic communities have to understand that the dynamics in commercial software are can be *very* different needs and have to show some open-mindedness there. > The multiprocessing package has almost the same API as you would get > from your suggestion, the only difference being that multiple > processes is involved. As other posts have gone into extensive detail, multiprocessing unfortunately don't handle the massive/complex data structures situation (see my posts regarding real-time video processing). I'm not sure if you've followed all the discussion, but multiple processes is off the table (this is discussed at length, so just flip back into the thread history). Andy -- http://mail.python.org/mailman/listinfo/python-list
