On Fri, Oct 31, 2008 at 11:55 AM, Brian Granger <ellisonbg.net at gmail.com> wrote: >>> Has anyone made the argument for keeping the GIL to discourage >>> threading? >> >> Oooh, you are on to my secret plan! :-) > > I completely agree that there are other approaches to parallelism and > concurrency that are much better than threading. However, I don't > think this is a good argument for having poor support for parallel > threads in Python (i.e. keeping the GIL). The reason is that threads > are extremely useful (and often required) for implementing other > approaches to concurrency, such as message passing. Two examples: > > Take Erlang for example. Erlang uses a shared nothing/message passing > approach to concurrency (Yes!). However, Erlangs implementation of > this approach relies heavily upon threads in the low-level of the > interpreter. Without this usage of threads Erlang would be able to > provide the multicore scalability that it does using message passing. > > Same is true of MPI. From the user's perspective MPI is just message > passing. But, MPI implementations use threads internally extensively. > > Bottom line: threads may be a bad end in themselves (I agree with > this), but they are a great means to better things. Despite the name, safethread has more to do with erlang than it does traditional threading. Alas, greenmicropseudothreadactormonitortaskfibreropebobprocess is a little too long for normal use, so I'm gonna keep calling it thread (and to distinguish it from an OS process). -- Adam Olsen, aka Rhamphoryncus
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4