Python 'threads' are the same pthreads turds all other lunix junk uses. The only difference is that the interpreter itself is not threadsafe, so they have a global lock which means threads suck even more than usual.
Forking a python interpreter is a *bad* idea, because python's start up takes billions of years. This has nothing to do with the merits of fork, and all with how much python sucks. There is Stackless Python, which has proper CSP threads/procs and channels, very similar to limbo. http://www.stackless.com/ But that is too sane for the mainline python folks obviously, so they stick to the pthrereads turds, ... My advice: unless you can use Stackless, stay as far away as you can from any concurrent python stuff. (And don't get me started on twisted and their event based hacks). Oh, and as I mentioned in another thread, in my experience if you are going to fork, make sure you compile statically, dynamic linking is almost as evil as pthreads. But this is lunix, so what do you expect? uriel On Tue, Mar 3, 2009 at 4:19 PM, David Leimbach <[email protected]> wrote: > > > On Tue, Mar 3, 2009 at 3:52 AM, hugo rivera <[email protected]> wrote: >> >> Hi, >> this is not really a plan 9 question, but since you are the wisest >> guys I know I am hoping that you can help me. >> You see, I have to launch many tasks running in parallel (~5000) in a >> cluster running linux. Each of the task performs some astronomical >> calculations and I am not pretty sure if using fork is the best answer >> here. >> First of all, all the programming is done in python and c, and since >> we are using os.fork() python facility I think that it is somehow >> related to the underlying c fork (well, I really do not know much of >> forks in linux, the few things I do know about forks and threads I got >> them from Francisco Ballesteros' "Introduction to operating system >> abstractions"). > > My knowledge on this subject is about 8 or 9 years old, so check with your local Python guru.... > The last I'd heard about Python's threading is that it was cooperative only, > and that you couldn't get real parallelism out of it. It serves as a means > to organize your program in a concurrent manner. > In other words no two threads run at the same time in Python, even if you're > on a multi-core system, due to something they call a "Global Interpreter > Lock". > >> >> The point here is if I should use forks or threads to deal with the job at >> hand? >> I heard that there are some problems if you fork too many processes (I >> am not sure how many are too many) so I am thinking to use threads. >> I know some basic differences between threads and forks, but I am not >> aware of the details of the implementation (probably I will never be). >> Finally, if this is a question that does not belong to the plan 9 >> mailing list, please let me know and I'll shut up. >> Saludos > > I think you need to understand the system limits, which is something you can > look up for yourself. Also you should understand what kind of runtime model > threads in the language you're using actually implements. > Those rules basically apply to any system. > >> >> -- >> Hugo >> > >
