Re: Kill GIL

In article <[EMAIL PROTECTED]>, Adrian Casey <[EMAIL PROTECTED]> wrote: >Aahz wrote: >> In article <[EMAIL PROTECTED]>, >> Frans Englich <[EMAIL PROTECTED]> wrote: >>> >>>Personally I need a solution which touches this discussion. I need to run >>>multiple processes, which I communicate with via

Re: Kill GIL

Adrian Casey wrote: Aahz wrote: Threads and forks tend to be problematic. This is one case I'd recommend against threads. Multiple threads interacting with stdin/stdout? I've done it with 2 queues. One for feeding the threads input and one for them to use for output. In fact, using queues takes

Re: Kill GIL

Aahz wrote: > In article <[EMAIL PROTECTED]>, > Frans Englich <[EMAIL PROTECTED]> wrote: >> >>Personally I need a solution which touches this discussion. I need to run >>multiple processes, which I communicate with via stdin/out, >>simultaneously, and my plan was to do this with threads. Any favo

Re: Kill GIL

In article <[EMAIL PROTECTED]>, Donn Cave <[EMAIL PROTECTED]> wrote: >In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Aahz) >wrote: >> >> Yes. I just get a bit irritated with some of the standard lines that >> people use. > >Hey, stop me if you've heard this one: "I used threads to solve >my

Re: Kill GIL

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Aahz) wrote: > Yes. I just get a bit irritated with some of the standard lines that > people use. Hey, stop me if you've heard this one: "I used threads to solve my problem - and now I have two problems!" Donn Cave, [EMAIL PROTECTED] -- h

Re: Kill GIL (was Re: multi threading in multi processor (computer))

[EMAIL PROTECTED] (Aahz) writes: > >[phr] The day is coming when even cheap computers have multiple cpu's. > >See hyperthreading and the coming multi-core P4's, and the finally > >announced Cell processor. > > > >Conclusion: the GIL must die. > > It's not clear to what extent these processors will

Re: Kill GIL

In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] (Aahz) writes: >> >> (Have you >> actually written any threaded applications in Python?) > >Yes. Have you ever asked a polite question? Yes. I just get a bit irritated with some of the standard lines that pe

Re: Kill GIL

[EMAIL PROTECTED] (Aahz) writes: > (Have you > actually written any threaded applications in Python?) Yes. Have you ever asked a polite question? http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.py

Re: Kill GIL

In article <[EMAIL PROTECTED]>, Dave Brueck <[EMAIL PROTECTED]> wrote: > Donn Cave wrote: [... re stackless inside-out event loop ] > > I put that together with real OS threads once, where the I/O loop was a > > message queue instead of select. A message queueing multi-threaded > > architecture c

Re: Kill GIL

Donn Cave wrote: Quoth Dave Brueck <[EMAIL PROTECTED]>: ... | Another related benefit is that a lot of application state is implicitly and | automatically managed by your local variables when the task is running in a | separate thread, whereas other approaches often end up forcing you to think in

Re: Kill GIL

Quoth Dave Brueck <[EMAIL PROTECTED]>: ... | Another related benefit is that a lot of application state is implicitly and | automatically managed by your local variables when the task is running in a | separate thread, whereas other approaches often end up forcing you to think in | terms of a sta

Re: Kill GIL

Mike Meyer wrote: [EMAIL PROTECTED] (Aahz) writes: In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote: Here here. I find that threading typically introduces worse problems than it purports to solve. Threads are also good for handling blocking I/O. Actually, this is one of the c

Re: Kill GIL

Mike Meyer wrote: [EMAIL PROTECTED] (Aahz) writes: Threads are also good for handling blocking I/O. Actually, this is one of the cases I was talking about. I find it saner to convert to non-blocking I/O and use select() for synchronization. That solves the problem, without introducing any of the he

Re: Kill GIL

In article <[EMAIL PROTECTED]>, Frans Englich <[EMAIL PROTECTED]> wrote: > >Personally I need a solution which touches this discussion. I need to run >multiple processes, which I communicate with via stdin/out, simultaneously, >and my plan was to do this with threads. Any favorite document point

Re: Kill GIL

On Monday 14 February 2005 00:53, Aahz wrote: > In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote: > >[EMAIL PROTECTED] (Aahz) writes: > >> In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote: > >>>Here here. I find that threading typically introduces worse p

Re: Kill GIL

In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] (Aahz) writes: >> In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote: >>> >>>Here here. I find that threading typically introduces worse problems >>>than it purports to solve. >> >> Threads

Re: Kill GIL

Mike Meyer <[EMAIL PROTECTED]> writes: > > Threads are also good for handling blocking I/O. > > Actually, this is one of the cases I was talking about. I find it > saner to convert to non-blocking I/O and use select() for > synchronization. That solves the problem, without introducing any of > the

Re: Kill GIL

>Actually, this is one of the cases I was talking about. I find it >saner to convert to non-blocking I/O and use select() for >synchronization. That solves the problem, without introducing any of >the headaches related to shared access and locking that come with >threads. Threads aren't always th

Re: Kill GIL

[EMAIL PROTECTED] (Aahz) writes: > In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote: >> >>Here here. I find that threading typically introduces worse problems >>than it purports to solve. > Threads are also good for handling blocking I/O. Actually, this is one of the cases I

Re: Kill GIL

In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote: > >Here here. I find that threading typically introduces worse problems >than it purports to solve. Depends what you're trying to do with threads. Threads are definitely a good technique for managing long-running work in a GUI

Re: Kill GIL

Mike Meyer wrote: Jack Diederich <[EMAIL PROTECTED]> writes: From reading this thread every couple months on c.l.py for the last few years it is my opinion that the number of people who think threading is the only solution to their problem greatly outnumber the number of people who actually have

Re: Kill GIL

>Here here. I find that threading typically introduces worse problems >than it purports to solve. I recently worked on a software effort, arguably one of the most important software efforts in existence, in which individuals responsible for critical performance of the application threw arbitraril

Re: Kill GIL

Jack Diederich <[EMAIL PROTECTED]> writes: > From reading this > thread every couple months on c.l.py for the last few years it is my > opinion that the number of people who think threading is the only solution > to their problem greatly outnumber the number of people who actually have > such a

Re: Kill GIL (was Re: multi threading in multi processor (computer))

>Killing the GIL is proposing a silver bullet where there is no werewolf-ly, About the only reason for killing the GIL is /us/. We, purists, pythonistas, language nuts, or what not, who for some reason or other simply hate the idea of the GIL. I'd view it as an artistic desire, unurgent, somethin

Re: Kill GIL (was Re: multi threading in multi processor (computer))

On Sat, Feb 12, 2005 at 07:13:17PM -0500, Aahz wrote: > In article <[EMAIL PROTECTED]>, > Paul Rubin wrote: > > > >The day is coming when even cheap computers have multiple cpu's. > >See hyperthreading and the coming multi-core P4's, and the finally > >announced Cell pro

Kill GIL (was Re: multi threading in multi processor (computer))

In article <[EMAIL PROTECTED]>, Paul Rubin wrote: > >The day is coming when even cheap computers have multiple cpu's. >See hyperthreading and the coming multi-core P4's, and the finally >announced Cell processor. > >Conclusion: the GIL must die. It's not clear to what e