[issue5840] "Thread State and the Global Interpreter Lock" section of the docs doesn't cover TLS APIs

Irit Katriel added the comment: Indeed, this API was deprecated in 3.7: https://docs.python.org/3/c-api/init.html#thread-local-storage-tls-api -- nosy: +iritkatriel resolution: -> out of date stage: needs patch -> resolved status: open -> closed

[issue5840] "Thread State and the Global Interpreter Lock" section of the docs doesn't cover TLS APIs

Cheryl Sabella added the comment: I believe this issue is superseded by PEP539 and issue25658? -- nosy: +csabella ___ Python tracker

[issue5840] Thread State and the Global Interpreter Lock section of the docs doesn't cover TLS APIs

Antoine Pitrou pit...@free.fr added the comment: Actually, I don't think the TLS APIs should be documented. They are quite internal, and used only for the PyGILState APIs. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org

[issue5840] Thread State and the Global Interpreter Lock section of the docs doesn't cover TLS APIs

Antoine Pitrou pit...@free.fr added the comment: They are used by pyOpenSSL and pygobject/pyglib, though :/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5840 ___

[issue5840] Thread State and the Global Interpreter Lock section of the docs doesn't cover TLS APIs

Georg Brandl ge...@python.org added the comment: Committed init.rst.diff in r72037. Next step: document TLS APIs. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5840 ___

[issue5840] Thread State and the Global Interpreter Lock section of the docs doesn't cover TLS APIs

. -- assignee: georg.brandl components: Documentation messages: 86501 nosy: exarkun, georg.brandl severity: normal status: open title: Thread State and the Global Interpreter Lock section of the docs doesn't cover TLS APIs type: feature request ___ Python

[issue5840] Thread State and the Global Interpreter Lock section of the docs doesn't cover TLS APIs

Jeroen Ruigrok van der Werven asmo...@in-nomine.org added the comment: This is at least relevant to 2.7, reflect this in the issue. Patch to remove the notion we don't support TLS yet. We will need to see where to add the current functions in the overall scheme of threading documentation.

[issue5840] Thread State and the Global Interpreter Lock section of the docs doesn't cover TLS APIs

Georg Brandl ge...@python.org added the comment: Looks good. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5840 ___ ___ Python-bugs-list

Re: Will Python 3.0 remove the global interpreter lock (GIL)

2 On Sep 19, 5:08 pm, Terry Reedy [EMAIL PROTECTED] wrote: Terry Reedy [EMAIL PROTECTED] wrote in message This assumes that comparing versions of 1.5 is still relevant. As far as I know, his patch has not been maintained to apply against current Python. This tells me that no one to date

Re: Will Python 3.0 remove the global interpreter lock (GIL)

Steven D'Aprano [EMAIL PROTECTED] wrote: I think a better question is, how much faster/slower would Stein's code be on today's processors, versus CPython being hand-simulated in a giant virtual machine made of clockwork? This obviously depends on whether or not the clockwork is orange

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On 20 Sep, 00:59, TheFlyingDutchman [EMAIL PROTECTED] wrote: Paul it's a pleasure to see that you are not entirely against complaints. Well, it seems to me that I'm usually the one making them. ;-) The very fastest Intel processor of the last 1990's that I found came out in October 1999 and

Re: Will Python 3.0 remove the global interpreter lock (GIL)

TheFlyingDutchman a écrit : (snip) I am confused about the benefits/disadvantages of the GIL removal. Is it correct that the GIL is preventing CPython from having threads? Is it correct that the only issue with the GIL is the prevention of being able to do multi-threading?

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On 9/19/07, TheFlyingDutchman [EMAIL PROTECTED] wrote: On Sep 19, 5:08 pm, Terry Reedy [EMAIL PROTECTED] wrote: Terry Reedy [EMAIL PROTECTED] wrote in message This is a little confusing because google groups does not show your original post (not uncommon for them to lose a post in a thread -

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On 2007-09-20, TheFlyingDutchman [EMAIL PROTECTED] wrote: Is the only point in getting rid of the GIL to allow multi-threaded applications? That's the main point. Can't multiple threads also provide a performance boost versus multiple processes on a single-core machine? That depends on the

Re: Will Python 3.0 remove the global interpreter lock (GIL)

Steven D'Aprano [EMAIL PROTECTED] writes: That's why your comparatively wimpy site preferred to throw extra web servers at the job of serving webpages rather than investing in smarter, harder-working programmers to pull the last skerricks of performance out of the hardware you already had.

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On 20 Sep 2007 07:43:18 -0700, Paul Rubin http://phr.cx@nospam.invalid wrote: Steven D'Aprano [EMAIL PROTECTED] writes: That's why your comparatively wimpy site preferred to throw extra web servers at the job of serving webpages rather than investing in smarter, harder-working programmers

Re: Will Python 3.0 remove the global interpreter lock (GIL)

Chris Mellon [EMAIL PROTECTED] writes: No. Python has threads, and they're wrappers around true OS level system threads. What the GIL does is prevent *Python* code in those threads from running concurrently. Well, C libraries can release the GIL if they are written for thread safety, but as

Re: Will Python 3.0 remove the global interpreter lock (GIL)

Chris Mellon [EMAIL PROTECTED] writes: The compute intensive stuff (image rendering and crunching) has already had most of those skerricks pulled out. It is written in C and assembler That means that this part is also unaffected by the GIL. Right, it was a counterexample against the speed

Re: Will Python 3.0 remove the global interpreter lock (GIL)

Paul Rubin http://phr.cx@NOSPAM.invalid wrote in message news:[EMAIL PROTECTED] | funding into PyPy development, since I think I saw something about the | EU funding being interrupted. As far as I know, the project was completed and promised funds paid. But I don't know of any major follow-on

Re: Will Python 3.0 remove the global interpreter lock (GIL)

Paul Rubin http://phr.cx@NOSPAM.invalid wrote in message news:[EMAIL PROTECTED] | It does sound like removing the GIL from CPython would have very high | costs in more than one area. Is my hope that Python will transition | from CPython to PyPy overoptimistic? I presume you mean 'will the

Re: Will Python 3.0 remove the global interpreter lock (GIL)

Ben Finney a écrit : (snip) One common response to that is Processes are expensive on Win32. My response to that is that if you're programming on Win32 and expecting the application to scale well, you already have problems that must first be addressed that are far more fundamental than the

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On 2007-09-19, Steven D'Aprano [EMAIL PROTECTED] wrote: On Tue, 18 Sep 2007 18:09:26 -0700, TheFlyingDutchman wrote: How much faster/slower would Greg Stein's code be on today's processors versus CPython running on the processors of the late 1990's? I think a better question is, how much

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Tue, 18 Sep 2007 18:09:26 -0700, TheFlyingDutchman wrote: How much faster/slower would Greg Stein's code be on today's processors versus CPython running on the processors of the late 1990's? I think a better question is, how much faster/slower would Stein's code be on today's processors,

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Sep 19, 8:51 am, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: On Tue, 18 Sep 2007 18:09:26 -0700, TheFlyingDutchman wrote: How much faster/slower would Greg Stein's code be on today's processors versus CPython running on the processors of the late 1990's? I think a better

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On 19 Sep, 03:09, TheFlyingDutchman [EMAIL PROTECTED] wrote: How much faster/slower would Greg Stein's code be on today's processors versus CPython running on the processors of the late 1990's? And if you decide to answer, please add a true/false response to this statement - CPython in the

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Sep 19, 3:41 pm, Paul Boddie [EMAIL PROTECTED] wrote: On 19 Sep, 03:09, TheFlyingDutchman [EMAIL PROTECTED] wrote: How much faster/slower would Greg Stein's code be on today's processors versus CPython running on the processors of the late 1990's? And if you decide to answer, please

Re: Will Python 3.0 remove the global interpreter lock (GIL)

Terry Reedy [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | | TheFlyingDutchman [EMAIL PROTECTED] wrote in message | news:[EMAIL PROTECTED] | Since Guido wrote that, there have been put forth more ideas and interest | and promises of efforts to remove or revise the GIL or do other

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Wed, 19 Sep 2007 11:07:48 -0700, TheFlyingDutchman wrote: On Sep 19, 8:51 am, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: On Tue, 18 Sep 2007 18:09:26 -0700, TheFlyingDutchman wrote: How much faster/slower would Greg Stein's code be on today's processors versus CPython

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Wed, 19 Sep 2007 15:59:59 -0700, TheFlyingDutchman wrote: Paul it's a pleasure to see that you are not entirely against complaints. I'm not against complaints either, so long as they are well-thought out. I've made a few of my own over the years, some of which may have been less

Re: Will Python 3.0 remove the global interpreter lock (GIL)

TheFlyingDutchman [EMAIL PROTECTED] writes: The very fastest Intel processor of the last 1990's that I found came out in October 1999 and had a speed around 783Mhz. Current fastest processors are something like 3.74 Ghz, with larger caches. Memory is also faster and larger. It appears that

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Wed, 19 Sep 2007 19:14:39 -0700, Paul Rubin wrote: We get cpu speed increases now through parallelism, not mhz. Intel and AMD both have 4-core cpu's now and Intel has a 16-core chip coming. Python is at a serious disadvantage compared with other languages if the other languages keep up

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Sep 19, 8:54 pm, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: On Wed, 19 Sep 2007 19:14:39 -0700, Paul Rubin wrote: etc. is at best an excuse for laziness. What are you doing about solving the problem? Apart from standing on the side-lines calling out Get yer lazy

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Sep 19, 5:08 pm, Terry Reedy [EMAIL PROTECTED] wrote: Terry Reedy [EMAIL PROTECTED] wrote in message This is a little confusing because google groups does not show your original post (not uncommon for them to lose a post in a thread - but somehow still reflect the fact that it exists in the

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Sep 2, 5:38 pm, Eduardo O. Padoan [EMAIL PROTECTED] wrote: No.http://www.artima.com/weblogs/viewpost.jsp?thread=211430 Ops, I meant:http://www.artima.com/forums/threaded.jsp?forum=106thread=211200 --http://www.advogato.org/person/eopadoan/ Bookmarks:http://del.icio.us/edcrypt No. We're

Re: Will Python 3.0 remove the global interpreter lock (GIL)

TheFlyingDutchman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | On Sep 2, 5:38 pm, Eduardo O. Padoan [EMAIL PROTECTED] | wrote: | No.http://www.artima.com/weblogs/viewpost.jsp?thread=211430 | | Ops, I meant:http://www.artima.com/forums/threaded.jsp?forum=106thread=211200 | |

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Sun, 2007-09-02 at 17:21 -0700, llothar wrote: I'm afraid that the GIL is killing the usefullness of python for some types of applications now where 4,8 oder 64 threads on a chip are here or comming soon. What is the status about that for the future of python? The GIL is an

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Sep 3, 2:21 am, llothar [EMAIL PROTECTED] wrote: I'm afraid that the GIL is killing the usefullness of python for some types of applications now where 4,8 oder 64 threads on a chip are here or comming soon. What is the status about that for the future of python? This is FAQ. You will find

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Sep 3, 9:15 am, Michele Simionato [EMAIL PROTECTED] wrote: On Sep 3, 2:21 am, llothar [EMAIL PROTECTED] wrote: My personal opinion (and I am not the only one in the Python community) is that if you want to scale the way to go is to use processes, not threads, so removing the GIL would be

Re: Will Python 3.0 remove the global interpreter lock (GIL)

Michele Simionato [EMAIL PROTECTED] writes: On Sep 3, 2:21 am, llothar [EMAIL PROTECTED] wrote: I'm afraid that the GIL is killing the usefullness of python for some types of applications now where 4,8 oder 64 threads on a chip are here or comming soon. This is FAQ. You will find

Re: Will Python 3.0 remove the global interpreter lock (GIL)

I was wondering (and maybe i still do) about this GIL problem. I am relatively new to Python (less than a year) and when i started to think about it i said: Oh, this IS a problem. But when i dig a little more, i found that Ah, maybe it isn't. I strongly believe that the best usage of multiple

Re: Will Python 3.0 remove the global interpreter lock (GIL)

I was wondering (and maybe i still do) about this GIL problem. I am relatively new to Python (less than a year) and when i started to think about it i said: Oh, this IS a problem. But when i dig a little more, i found that Ah, maybe it isn't. I strongly believe that the best usage of multiple

Re: Will Python 3.0 remove the global interpreter lock (GIL)

I was wondering (and maybe i still do) about this GIL problem. I am relatively new to Python (less than a year) and when i started to think about it i said: Oh, this IS a problem. But when i dig a little more, i found that Ah, maybe it isn't. I strongly believe that the best usage of multiple

Will Python 3.0 remove the global interpreter lock (GIL)

I'm afraid that the GIL is killing the usefullness of python for some types of applications now where 4,8 oder 64 threads on a chip are here or comming soon. What is the status about that for the future of python? I know that at the moment allmost nobody in the scripting world has solved this

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On 9/2/07, llothar [EMAIL PROTECTED] wrote: I'm afraid that the GIL is killing the usefullness of python for some types of applications now where 4,8 oder 64 threads on a chip are here or comming soon. What is the status about that for the future of python? I know that at the moment allmost

Re: Will Python 3.0 remove the global interpreter lock (GIL)

No. http://www.artima.com/weblogs/viewpost.jsp?thread=211430 Ops, I meant: http://www.artima.com/forums/threaded.jsp?forum=106thread=211200 -- http://www.advogato.org/person/eopadoan/ Bookmarks: http://del.icio.us/edcrypt -- http://mail.python.org/mailman/listinfo/python-list

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On 3 Sep., 07:38, Eduardo O. Padoan [EMAIL PROTECTED] wrote: No.http://www.artima.com/weblogs/viewpost.jsp?thread=211430 Ops, I meant:http://www.artima.com/forums/threaded.jsp?forum=106thread=211200 Thanks. I whish there would be a project for rewritting the C interpreter to make it better

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Sep 2, 11:16 pm, llothar [EMAIL PROTECTED] wrote: On 3 Sep., 07:38, Eduardo O. Padoan [EMAIL PROTECTED] wrote: No.http://www.artima.com/weblogs/viewpost.jsp?thread=211430 Ops, I meant:http://www.artima.com/forums/threaded.jsp?forum=106thread=211200 Thanks. I whish there would be a

Re: global interpreter lock

Thanks, PyThread_release_lock() is implemented in all thread_xxx.h files. So I thought right but specified my question like a stupid ;) //T -- http://mail.python.org/mailman/listinfo/python-list

global interpreter lock

I just need confirmation that I think right. Is the files thread_xxx.h (xxx = nt, os2 or whatever) responsible for the global interpreter lock in a multithreaded environment? I'm currently writing my own thread_VW for VxWorks, thats why I'm asking. //Tommy -- http://mail.python.org/mailman

Re: global interpreter lock

[EMAIL PROTECTED] wrote: I just need confirmation that I think right. Is the files thread_xxx.h (xxx = nt, os2 or whatever) responsible for the global interpreter lock in a multithreaded environment? I'm currently writing my own thread_VW for VxWorks, thats why I'm asking. //Tommy

Re: global interpreter lock

Stephen Thorne wrote: On 15/09/05, Michael Sparks [EMAIL PROTECTED] wrote: At the moment, one option that springs to mind is this: yield WaitDataAvailable(inbox) Twisted supports this. help(twisted.internet.defer.waitForDeferred) Thanks for this. I'll take a look and either we'll

Re: global interpreter lock

It looks like I am reinventing Twisted and/or Kamelia. This is code I wrote just today to simulate Python 2.5 generator in current Python: import Queue class coroutine(object): def __init__(self, *args, **kw): self.queue = Queue.Queue() self.it = self.__cor__(*args, **kw)

Re: global interpreter lock

Michele Simionato wrote: It looks like I am reinventing Twisted and/or Kamaelia. If it's /fun/ , is that a problem ? ;) (Interesting implementation BTW :) FWIW, I've about a year ago it wasn't clear if we would be able to release our stuff, so as part of a presentation I included a

Re: global interpreter lock

Paul Rubin wrote: ... I don't see how generators substitute for microthreads. In your example from another post: I've done some digging and found what you mean by microthreads - specifically I suspect you're referring to the microthreads package for stackless? (I tend to view an activated

Re: global interpreter lock

[ Second time lucky... ] Paul Rubin wrote: ... I don't see how generators substitute for microthreads. In your example from another post: I've done some digging and found what you mean by microthreads - specifically I suspect you're referring to the microthreads package for stackless? (I tend

Re: global interpreter lock

On 15/09/05, Michael Sparks [EMAIL PROTECTED] wrote: At the moment, one option that springs to mind is this: yield WaitDataAvailable(inbox) Twisted supports this. help(twisted.internet.defer.waitForDeferred) example usage is: @deferredGenerator def thingummy(): thing =

Re: global interpreter lock

Michael Sparks [EMAIL PROTECTED] writes: But I think to do it on Erlang's scale, Python needs user-level microthreads and not just OS threads. You've just described Kamaelia* BTW, except substitute micro-thread with generator :-) (Also we call the queues outboxes and inboxes, and the

Re: global interpreter lock

Dennis Lee Bieber [EMAIL PROTECTED] writes: On Wed, 31 Aug 2005 22:44:06 -0400, Mike Meyer [EMAIL PROTECTED] declaimed the following in comp.lang.python: I don't know what Ada offers. Java gives you pseudo-monitors. I'm From the days of mil-std 1815, Ada has supported tasks which

Re: global interpreter lock

Mike Meyer wrote: Bryan Olson writes: System support for threads has advanced far beyond what Mr. Meyer dealt with in programming the Amiga. I don't think it has - but see below. In industry, the two major camps are Posix threads, and Microsoft's Win32 threads (on NT or better). Some

Re: global interpreter lock

Mike Meyer [EMAIL PROTECTED] writes: Sure. I tried to be helpful there, but maybe I need to be more specific. The ref from my previous post, Google-able as The C10K problem is good but now a little dated. That appears to be a discussion on squeezing the most out of a network server,

Re: global interpreter lock

Dennis Lee Bieber wrote: On Thu, 01 Sep 2005 06:15:38 GMT, Bryan Olson [EMAIL PROTECTED] declaimed the following in comp.lang.python: With Python threads/queues how do I wait for two queues (or Why have two queues? Use one queue and tag the items with the sender's id (or return queue).

Re: global interpreter lock

Dennis Lee Bieber wrote: Well, at that point, you could substitute waiting on a queue with waiting on a socket and still have the same problem -- regardless of the nature of the language/libraries for threading; it's a problem with the design of the classes as applied to a threaded

Re: global interpreter lock

Bryan Olson [EMAIL PROTECTED] writes: Mike Meyer wrote: Bryan Olson writes: System support for threads has advanced far beyond what Mr. Meyer dealt with in programming the Amiga. I don't think it has - but see below. In industry, the two major camps are Posix threads, and

Re: global interpreter lock

Mike Meyer wrote: Bryan Olson writes: With Python threads/queues how do I wait for two queues (or locks or semaphores) at one call? (I know some methods to accomplish the same effect, but they suck.) By not as good as, I meant the model they provide isn't as managable as the one

Re: global interpreter lock

phil hunt wrote: Some times concurrency is the best (or only) way to do a job. Other times, it's more trouble than its worth. A good programmer will know which is which, and will not use an overly complex solution for the project he is writing. Also, a good programmer won't conflate

Re: global interpreter lock

Bengt Richter wrote: Bryan Olson wrote: For a long time, the most sophisticated software services generally have used multiple lines of execution, and now that's mostly in the form of threads. No one actually disagrees, but they go right on knocking the modern methods. I think Mike is

Re: global interpreter lock

Bryan Olson [EMAIL PROTECTED] writes: Bengt Richter wrote: Bryan Olson wrote: For a long time, the most sophisticated software services generally have used multiple lines of execution, and now that's mostly in the form of threads. No one actually disagrees, but they go right on

Re: global interpreter lock

On Sun, 28 Aug 2005 20:34:07 GMT, Bryan Olson [EMAIL PROTECTED] wrote: phil hunt wrote: Yes, find solutions. Don't find dangerous dead-ends that look like solutions but which will give you lots of trouble. If concurrency is a dead end, why do the programs that provide the most sophisticated

Re: global interpreter lock

On Sun, 28 Aug 2005 19:25:55 -0400, Mike Meyer [EMAIL PROTECTED] wrote: Bryan Olson [EMAIL PROTECTED] writes: phil hunt wrote: Yes, find solutions. Don't find dangerous dead-ends that look like solutions but which will give you lots of trouble. If concurrency is a dead end, why do the

Re: global interpreter lock

On Tue, 30 Aug 2005 05:15:34 GMT, Bryan Olson [EMAIL PROTECTED] wrote: Mike Meyer wrote: Bryan Olson [EMAIL PROTECTED] writes: Bryan Olson writes: Trivially, an 'if' statement that depends upon input data is statically predictable. Use of async I/O means makes the programs execution

Re: global interpreter lock

[EMAIL PROTECTED] (Bengt Richter) writes: On Tue, 30 Aug 2005 05:15:34 GMT, Bryan Olson [EMAIL PROTECTED] wrote: Mike Meyer wrote: Bryan Olson [EMAIL PROTECTED] writes: Bryan Olson writes: Trivially, an 'if' statement that depends upon input data is statically predictable. Use of async

Re: global interpreter lock

Mike Meyer wrote: Bryan Olson writes: phil hunt wrote: What's important is *predictability*, e.g. which instruction will the computer execute next? If you only have one thread, you can tell by looking at the code what gets executed next. It's very simple. Not really.

Re: global interpreter lock

Bryan Olson [EMAIL PROTECTED] writes: Mike Meyer wrote: Bryan Olson writes: phil hunt wrote: What's important is *predictability*, e.g. which instruction will the computer execute next? If you only have one thread, you can tell by looking at the code what gets executed next.

Re: global interpreter lock

Mike Meyer wrote: Bryan Olson [EMAIL PROTECTED] writes: Bryan Olson writes: Trivially, an 'if' statement that depends upon input data is statically predictable. Use of async I/O means makes the programs execution dependent upon external timing. Mike Meyer wrote: Yes, but that

Re: global interpreter lock

phil hunt wrote: It's not the number of paths that's important. Absolutely right. Non-trivial software always has too many paths to consider them individually, so we have to reason generally. What's important is *predictability*, e.g. which instruction will the computer execute next?

Re: global interpreter lock

Piet van Oostrum wrote: Paul Rubin http://[EMAIL PROTECTED] (PR) wrote: PR Really, the essence of programming is to find ways of organizing the PR program to stay reliable and maintainable in the face of that PR combinatorial explosion. That means facing the problem and finding PR solutions,

Re: global interpreter lock

Bryan Olson [EMAIL PROTECTED] writes: phil hunt wrote: What's important is *predictability*, e.g. which instruction will the computer execute next? If you only have one thread, you can tell by looking at the code what gets executed next. It's very simple. Not really. Trivially, an

Re: global interpreter lock

Paul Rubin http://[EMAIL PROTECTED] (PR) wrote: PR [EMAIL PROTECTED] (phil hunt) writes: Let's see. Reality is that writing correct programs is hard. Writing correct programs that use concurrency is even harder, because of the exponential explosion of the order that operations can happen in.

Re: global interpreter lock

Mike Meyer wrote: Bryan Olson [EMAIL PROTECTED] writes: The issue here is whether to confuse reality with what one might wish reality to be. Let's see. Reality is that writing correct programs is hard. Writing correct programs that use concurrency is even harder, because of the

Re: global interpreter lock

On Thu, 25 Aug 2005 00:56:10 -0400, Mike Meyer [EMAIL PROTECTED] wrote: The issue here is whether to confuse reality with what one might wish reality to be. Let's see. Reality is that writing correct programs is hard. Writing correct programs that use concurrency is even harder, because of the

Re: global interpreter lock

[EMAIL PROTECTED] (phil hunt) writes: Let's see. Reality is that writing correct programs is hard. Writing correct programs that use concurrency is even harder, because of the exponential explosion of the order that operations can happen in. Personally, I'm willing to use anything I can find

Re: global interpreter lock

On 26 Aug 2005 14:35:03 -0700, Paul Rubin http://[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (phil hunt) writes: Let's see. Reality is that writing correct programs is hard. Writing correct programs that use concurrency is even harder, because of the exponential explosion of the order that

Re: global interpreter lock

Paul Rubin http://[EMAIL PROTECTED] writes: [EMAIL PROTECTED] (phil hunt) writes: Let's see. Reality is that writing correct programs is hard. Writing correct programs that use concurrency is even harder, because of the exponential explosion of the order that operations can happen in.

Re: global interpreter lock

Mike Meyer wrote: Bryan Olson writes: Mike Meyer wrote: The rule I follow in choosing my tools is Use the least complex tool that will get the job done. Even if a more complex tool could do the job better? In that case, the simpler model isn't necessarily getting the job done.

Re: global interpreter lock

Bryan Olson [EMAIL PROTECTED] writes: Mike Meyer wrote: Bryan Olson writes: Mike Meyer wrote: The rule I follow in choosing my tools is Use the least complex tool that will get the job done. Even if a more complex tool could do the job better? In that case, the simpler model

Re: global interpreter lock

Paul Rubin http://[EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: Even simpler to program in is the model used by Erlang. It's more CSP than threading, though, as it doesn't have shared memory as part of the model. But if you can use the simpler model to solve your problem -

Re: global interpreter lock

Dennis Lee Bieber [EMAIL PROTECTED] writes: On Sat, 20 Aug 2005 22:30:43 -0400, Mike Meyer [EMAIL PROTECTED] declaimed the following in comp.lang.python: with these issues. If I ever find myself having to have non-trivial threads again, I'll check the state of the threading models in other

Re: global interpreter lock

Paul Rubin wrote: Mike Meyer [EMAIL PROTECTED] writes: Even simpler to program in is the model used by Erlang. It's more CSP than threading, though, as it doesn't have shared memory as part of the model. But if you can use the simpler model to solve your problem - you probably should.

Re: global interpreter lock

km wrote: is true parallelism possible in python ? or atleast in the coming versions ? is global interpreter lock a bane in this context ? I've had absolutely zero problems implementing truly parallel programs in python. All of my parallel programs have been multiprocess architectures, though

Re: global interpreter lock

[km] is true parallelism possible in python ? cpython:no. jython: yes. ironpython: yes. or atleast in the coming versions ? cpython:unknown. pypy: don't have time to research. Anyone know? is global interpreter lock a bane in this context ? beauty/bane-is-in-the-eye

Re: global interpreter lock

Quoth Paul Rubin http://[EMAIL PROTECTED]: | Mike Meyer [EMAIL PROTECTED] writes: | The real problem is that the concurrency models available in currently | popular languages are still at the goto stage of language | development. Better models exist, have existed for decades, and are | available

Re: global interpreter lock

Mike Meyer wrote: The real problem is that the concurrency models available in currently popular languages are still at the goto stage of language development. Better models exist, have existed for decades, and are available in a variety of languages. That's not the real problem; it's a

Re: global interpreter lock

[Bryan Olson] I don't see much point in trying to convince programmers that they don't really want concurrent threads. They really do. Some don't know how to use them, but that's largely because they haven't had them. I doubt a language for thread-phobes has much of a future. [Mike Meyer] The

Re: global interpreter lock

Donn Cave [EMAIL PROTECTED] writes: Quoth Paul Rubin http://[EMAIL PROTECTED]: | Mike Meyer [EMAIL PROTECTED] writes: | The real problem is that the concurrency models available in currently | popular languages are still at the goto stage of language | development. Better models exist, have

Re: global interpreter lock

Bryan Olson [EMAIL PROTECTED] writes: Mike Meyer wrote: The real problem is that the concurrency models available in currently popular languages are still at the goto stage of language development. Better models exist, have existed for decades, and are available in a variety of

Re: global interpreter lock

Mike Meyer [EMAIL PROTECTED] writes: Even simpler to program in is the model used by Erlang. It's more CSP than threading, though, as it doesn't have shared memory as part of the model. But if you can use the simpler model to solve your problem - you probably should. Well, ok, the Python

Re: global interpreter lock

Quoth Mike Meyer [EMAIL PROTECTED]: [... wandering from the nominal topic ...] | *) The most difficult task was writing horizontal microcode, which | also had serious concurrency issues in the form of device settling | times. I dealt with that by inventing a programming model that hid | most of

global interpreter lock

Hi all, is true parallelism possible in python ? or atleast in the coming versions ? is global interpreter lock a bane in this context ? regards, KM -- http://mail.python.org/mailman/listinfo/python-list

Re: global interpreter lock

km [EMAIL PROTECTED] writes: is true parallelism possible in python ? or atleast in the coming versions ? is global interpreter lock a bane in this context ? http://poshmodule.sf.net -- http://mail.python.org/mailman/listinfo/python-list

Re: global interpreter lock

Paul Rubin wrote: km [EMAIL PROTECTED] writes: is true parallelism possible in python ? or atleast in the coming versions ? is global interpreter lock a bane in this context ? http://poshmodule.sf.net Is posh maintained? The page mentions 2003 as the last date. -- Robin Becker -- http

  1   2   >