[Python-3000] the future of the GIL (original) (raw)
tomer filiba tomerfiliba at gmail.com
Mon May 7 13:21:39 CEST 2007
- Previous message: [Python-3000] the future of the GIL
- Next message: [Python-3000] the future of the GIL
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Talin]
Note that Jython and IronPython don't have the same restrictions in this regard as CPython. Both VMs are able to run in multiprocessing environments. (I don't know whether or not Jython/IronPython even have a GIL or not.)
they don't. they rely on jvm/clr for GC, and probably per-thread locking when they touch global data.
[Giovanni Bajo]
You seem to believe that the only way to parallelize your programs is to use threads. IMHO, threads is just the most common and absolutely the worst, under many points of views.
not at all. personally i hate threads, but there are many place where you can use them properly to distribute workload -- without mutual dependencies or shard state. this makes them essentially like light-weight processes, using background workers and queues, etc., only without the overhead of multiple processes.
there could be a stdlib threading module that would provide you with all kinds of queues, schedulers, locks, and decorators, so you wouldn't have to manually lock things every time.
-tomer
- Previous message: [Python-3000] the future of the GIL
- Next message: [Python-3000] the future of the GIL
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]