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

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

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 minimalisti

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

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 e

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 = waitForDe

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

arrgh... hit wrong keystroke which caused an early send before I'd finished typing... (skip the message I'm replying to hear for a minute please :-) Michael. -- http://mail.python.org/mailman/listinfo/python-list

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 gen

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

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" w

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

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

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 thre

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 retu

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 >

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 bett

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

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 th

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 concur

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 p

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 > >

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, w

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 sophis

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: >>

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 > >> > wh

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. >>N

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. Tr

Re: global interpreter lock

Piet van Oostrum wrote: >>Paul Rubin (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 findin

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

> Paul Rubin (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 operat

Re: global interpreter lock

Paul Rubin 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

Re: global interpreter lock

On 26 Aug 2005 14:35:03 -0700, Paul Rubin 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

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

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

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

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,

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

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 shoul

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

Re: global interpreter lock

Paul Rubin 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 pro

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, thou

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

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

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 vari

Re: global interpreter lock

"Donn Cave" <[EMAIL PROTECTED]> writes: > Quoth Paul Rubin : > | 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 m

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

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";

Re: global interpreter lock

Quoth Paul Rubin : | 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 |>

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

Mike Meyer <[EMAIL PROTECTED]> writes: > > 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

Re: global interpreter lock

Bryan Olson <[EMAIL PROTECTED]> writes: > 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 >

Re: global interpreter lock

Donn Cave wrote: > Bryan Olson wrote: >>On a uniprocessor system, the GIL is no problem. On multi- >>processor/core systems, it's a big loser. > > > I rather suspect it's a bigger winner there. > > Someone who needs to execute Python instructions in parallel > is out of luck, of course, b

Re: global interpreter lock

Would a cheap solution just be to run two python interpreters and have the scripts communicating over COM or some other such thing?  I'd imagine that would give you true parallelism. -GregOn 8/19/05, Donn Cave <[EMAIL PROTECTED]> wrote: In article <[EMAIL PROTECTED] >, Bryan Olson <[EMAIL PROTECTE

Re: global interpreter lock

In article <[EMAIL PROTECTED]>, Bryan Olson <[EMAIL PROTECTED]> wrote: > km wrote: > > Hi all, > > > > is true parallelism possible in python ? or atleast in the > > coming versions ? is global interpreter lock a bane in this > > context ? > > No; maybe; and currently, not usually. > > On

Re: global interpreter lock

km wrote: > Hi all, > > is true parallelism possible in python ? or atleast in the > coming versions ? is global interpreter lock a bane in this > context ? No; maybe; and currently, not usually. On a uniprocessor system, the GIL is no problem. On multi- processor/core systems, it's a big lo

Re: global interpreter lock

KM, I eagerly await the answer to this question as well.  I'd love to see this explained in laymen's terms.  From what I understand of this issue, your best bet for getting parrelism is to use whatever the OS provides and just have multiple python instances running... but then I didn't understan

Re: global interpreter lock

On 2005-08-20, km <[EMAIL PROTECTED]> wrote: > is true parallelism possible in python? No, not for some values of "true parallelism". > or atleast in the coming versions? Not that I'm aware of. > is global interpreter lock a bane in this context? In what context? -- Grant Edwards

Re: global interpreter lock

Robin Becker <[EMAIL PROTECTED]> writes: > > http://poshmodule.sf.net > Is posh maintained? The page mentions 2003 as the last date. Dunno, and I suspect not. I've been wondering about it myself. -- 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

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