Re: Python threading comparison

On Wed, Jun 23, 2021 at 5:34 AM Dan Stromberg wrote: > > I put together a little python runtime comparison, with an embarallel, > cpu-heavy threading microbenchmark. > > It turns out that the performance-oriented Python implementations, Pypy3 > and Nuitka3, are both poor at threading, as is CPytho

Python threading comparison

I put together a little python runtime comparison, with an embarallel, cpu-heavy threading microbenchmark. It turns out that the performance-oriented Python implementations, Pypy3 and Nuitka3, are both poor at threading, as is CPython of course. On the plus side for CPython, adding cpu-heavy thre

Re: Python threading - event

On 2019-02-17 09:52, Prahallad Achar wrote: Hello Friends, I got an requirement as stated below, 1. main thread will be running and other event should run parallel In more detail One function will be keep dumping data and other event function should trigger at some event but dumping data should

Python threading - event

Hello Friends, I got an requirement as stated below, 1. main thread will be running and other event should run parallel In more detail One function will be keep dumping data and other event function should trigger at some event but dumping data should be keep running. Sorry, I can not give any ex

Re: Python threading and sharing variables

On Wed, Jul 5, 2017 at 5:06 PM, Chris Angelico wrote: > On Thu, Jul 6, 2017 at 2:24 AM, eryk sun wrote: >>> But what could it do? Most likely, it's going to end up mutating a >>> dict (the core type), so unless the __setitem__ is itself maintaining >>> complex state that needs a lock, all you've

Re: Python threading and sharing variables

On Thu, Jul 6, 2017 at 2:24 AM, eryk sun wrote: >> But what could it do? Most likely, it's going to end up mutating a >> dict (the core type), so unless the __setitem__ is itself maintaining >> complex state that needs a lock, all you've done is move the problem >> around, and the same solutions w

Re: Python threading and sharing variables

On Wed, Jul 5, 2017 at 4:04 PM, Chris Angelico wrote: > On Thu, Jul 6, 2017 at 12:39 AM, eryk sun wrote: >>> This doesn't show a potential concurrency problem. Calculating a hash >>> on "cnt" is independent of other threads; the actual work of >>> __setitem__ isn't visible in this view. There cer

Re: Python threading and sharing variables

On Thu, Jul 6, 2017 at 12:39 AM, eryk sun wrote: >> This doesn't show a potential concurrency problem. Calculating a hash >> on "cnt" is independent of other threads; the actual work of >> __setitem__ isn't visible in this view. There certainly are places >> where a context switch could cause prob

Re: Python threading and sharing variables

On Wed, Jul 5, 2017 at 2:03 PM, Chris Angelico wrote: > On Wed, Jul 5, 2017 at 11:50 PM, eryk sun wrote: >> Assignment of a single variable in an unoptimized namespace isn't >> completely immune to this -- in principle. Think __setitem__, >> __getitem__, __hash__, and __eq__. For example: >> >>

Re: Python threading and sharing variables

On Wed, Jul 5, 2017 at 11:50 PM, eryk sun wrote: > Assignment of a single variable in an unoptimized namespace isn't > completely immune to this -- in principle. Think __setitem__, > __getitem__, __hash__, and __eq__. For example: > > >>> exec('cnt = 42; cnt = 43; cnt', NoisyNS()) > __seti

Re: Python threading and sharing variables

On Wed, Jul 5, 2017 at 12:14 PM, Peter Otten <__pete...@web.de> wrote: > Chris Angelico wrote: > >> You can be confident that a single assignment will happen atomically. >> Even if "self.cnt = i" requires multiple instructions to perform > > For name binding > > cnt = i > > maybe, but > > self.cnt

Re: Python threading and sharing variables

On Wed, Jul 5, 2017 at 8:40 PM, Rhodri James wrote: > On 05/07/17 09:26, Chris Angelico wrote: >> >> On Wed, Jul 5, 2017 at 5:56 PM, pozz wrote: >>> >>> It seems it works, but I'm not sure it is the correct way to share the >>> variable self.cnt. It is only written in the long thread and only rea

Re: Python threading and sharing variables

On Wed, Jul 5, 2017 at 10:14 PM, Peter Otten <__pete...@web.de> wrote: > Chris Angelico wrote: > >> You can be confident that a single assignment will happen atomically. >> Even if "self.cnt = i" requires multiple instructions to perform > > For name binding > > cnt = i > > maybe, but > > self.cnt

Re: Python threading and sharing variables

Chris Angelico wrote: > You can be confident that a single assignment will happen atomically. > Even if "self.cnt = i" requires multiple instructions to perform For name binding cnt = i maybe, but self.cnt = i can execute arbitrary Python code (think __setattr__()). With threads I'd rather p

Re: Python threading and sharing variables

On 05/07/17 09:26, Chris Angelico wrote: On Wed, Jul 5, 2017 at 5:56 PM, pozz wrote: It seems it works, but I'm not sure it is the correct way to share the variable self.cnt. It is only written in the long thread and only read in the main thread. Could a single Python instruction be interrupted

Re: Python threading and sharing variables

On Wed, Jul 5, 2017 at 6:57 PM, Thomas Nyberg wrote: > On 07/05/2017 10:40 AM, Chris Angelico wrote: >> What would the lock surround? > > Sorry yes I agree with you that no lock is needed in this method. I was > a bit confused by the code and probably was thinking something like "a > += 1" in my h

Re: Python threading and sharing variables

On 07/05/2017 10:40 AM, Chris Angelico wrote: > What would the lock surround? Sorry yes I agree with you that no lock is needed in this method. I was a bit confused by the code and probably was thinking something like "a += 1" in my head (even though that's not what he was doing...). Thanks for cl

Re: Python threading and sharing variables

On 07/05/2017 10:20 AM, Thomas Nyberg wrote: > [...snip...] Btw I forgot to mention that you'd probably want to use q.get_nowait() instead of q.get() in my code example if you don't want the main thread to block (which what I think you want to avoid from your code example). https://docs.

Re: Python threading and sharing variables

On Wed, Jul 5, 2017 at 6:26 PM, Thomas Nyberg wrote: > I think the general rule would be that no it's not safe to skip the > locks. It's true that with cpython, your method shouldn't run into > problems, but that's just a quirk of how you're using it. I look at from > another perspective, if it's

Re: Python threading and sharing variables

On Wed, Jul 5, 2017 at 5:56 PM, pozz wrote: > It seems it works, but I'm not sure it is the correct way to share the > variable self.cnt. It is only written in the long thread and only read in > the main thread. > Could a single Python instruction be interrupted (in this case, self.cnt = > i)? Sho

Re: Python threading and sharing variables

On 07/05/2017 10:05 AM, pozz wrote: > > Ok, maybe this atomic behaviour depends on the Python implementation, so > it's better to avoid relying on atomicity and use a lock to access > shared variables from different running thread. > > However in my simple case one thread writes the variable and

Re: Python threading and sharing variables

On 07/05/2017 09:56 AM, pozz wrote: > It seems it works, but I'm not sure it is the correct way to share the > variable self.cnt. It is only written in the long thread and only read > in the main thread. > Could a single Python instruction be interrupted (in this case, self.cnt > = i)? Should I use

Re: Python threading and sharing variables

Il 05/07/2017 09:56, pozz ha scritto: > [...] It seems it works, but I'm not sure it is the correct way to share the variable self.cnt. It is only written in the long thread and only read in the main thread. Could a single Python instruction be interrupted (in this case, self.cnt = i)? Should I

Python threading and sharing variables

I'd like to launch *and control* a long thread. I want to print the progress of the long thread in the main thread. It's a GUI script, here it's a console script only to simplify. import threading import time class MyClass: def start(self): self.max = 5 self.pause = 1

Re: Python threading/multiprocessing issue.

Dnia Fri, 15 Jul 2011 22:15:15 -0700, Dennis Lee Bieber napisał(a): > And (so far as I understand it) each process can claim its own CPU > core, whereas threads share the active core. I do not think so. AFAIK, threads may be distributed over differrent CPUs (just like in any other programmin

Re: Python threading/multiprocessing issue.

On Sat, Jul 16, 2011 at 3:15 PM, Dennis Lee Bieber wrote: > And (so far as I understand it) each process can claim its own CPU > core, whereas threads share the active core. Threads can be put onto separate cores too, and can have their affinities set. But because of the GIL, actual CPython code

Re: Python threading/multiprocessing issue.

2011/7/16 Lee Harr : > I am not a multiprocessing expert, but I think the problem you > are having is that Process is running your code in a separate > process, so there is no way you could see those object changes > in your main line code. > > In other words, Process is not an exact replacement fo

Re: Python threading/multiprocessing issue.

I see. Well I was hoping to see the same result in the multiprocessing example as using the threading example. What you pointed out makes sense though, but what I don't understand is how modifying the queue in the example works fine in both. Possibly it was designed for that kind of use? Brand

Re: Python threading/multiprocessing issue.

> I'm working on a tool that runs a number of process is separate thread. > I've, up to this point, been using threading.Thread, but from what I > read multiprocess will allow multiple processors to be used >  From the python docs on multiprocessing. > leverage multiple processors on a giv

Python threading/multiprocessing issue.

I'm working on a tool that runs a number of process is separate thread. I've, up to this point, been using threading.Thread, but from what I read multiprocess will allow multiple processors to be used From the python docs on multiprocessing. I have run into an issue when modifying the thread obj

Python threading/multiprocessing issue.

I'm working on a tool that runs a number of process is separate thread. I've, up to this point, been using threading.Thread, but from what I read multiprocess will allow multiple processors to be used From the python docs on multiprocessing. I have run into an issue when modifying the thread obj

[PYTHON] threading: Parallel processing

Hi All, Is there is a way to print or use the value of new in the main function of the script below? from thread import start_new_thread, allocate_lock num_threads = 0 thread_started = False lock = allocate_lock() def heron(a): global num_threads, thread_started lock.acquire() num_

Re: Status of Python threading support (GIL removal)?

"Paul Rubin" wrote: > "Hendrik van Rooyen" writes: > > I think that this is because (like your link has shown) the problem > > is really not trivial, and also because the model that can bring > > sanity to the party (independent threads/processes that communicate >

Re: Status of Python threading support (GIL removal)?

"Hendrik van Rooyen" writes: > I think that this is because (like your link has shown) the problem > is really not trivial, and also because the model that can bring > sanity to the party (independent threads/processes that communicate > with queued messages) is seen as inefficient at small scale.

Re: Status of Python threading support (GIL removal)?

In article , Jeremy Sanders wrote: >Jesse Noller wrote: >> >> Sorry, you're incorrect. I/O Bound threads do in fact, take advantage >> of multiple cores. > >I don't know whether anyone else brought this up, but it looks >like Python has problems with even this form of threading > >http://www.dab

Re: Status of Python threading support (GIL removal)?

In article <90303b55-8686-4d56-b89c-01e31d0a6...@l8g2000vbp.googlegroups.com>, =?windows-1252?Q?Jure_Erzno=9Enik?= wrote: > >So, recently I started writing a part of this new system in Python. A >report generator to be exact. Let's not go into existing offerings, >they are insufficient for our ne

Re: Status of Python threading support (GIL removal)?

Jesse Noller wrote: > Sorry, you're incorrect. I/O Bound threads do in fact, take advantage > of multiple cores. I don't know whether anyone else brought this up, but it looks like Python has problems with even this form of threading http://www.dabeaz.com/python/GIL.pdf It's certainly a very

Re: Status of Python threading support (GIL removal)?

Jure Erznožnik wrote: > On Jun 20, 1:36 am, a...@pythoncraft.com (Aahz) wrote: >> You should put up or shut up -- I've certainly seen multi-core speedup >> with threaded software, so show us your benchmarks! >> -- > > Sorry, no intent to offend anyone here. Flame wars are not my thing. > > I have

Re: Status of Python threading support (GIL removal)?

Christian Heimes wrote: > Hard computations gain more speed from carefully crafted C or Fortran > code that utilizes features like the L1 and L2 CPU cache, SIMD etc. or > parallelized algorithms. If you start sharing values between multiple > cores you have a serious problem. > > Oh, and use NumPy

Re: Status of Python threading support (GIL removal)?

"Kay Schluehr" wrote: > This implies that people stay defensive concerning concurrency ( like > me right now ) and do not embrace it like e.g. Erlang does. Sometimes > there is a radical change in the way we design applications and a > language is the appropriate medium to express it succinctly.

Re: Status of Python threading support (GIL removal)?

On Jun 21, 9:32 am, OdarR wrote: > > Do you think multiprocessing can help you seriously ? > Can you benefit from multiple cpu ? > > did you try to enhance your code with numpy ? > > Olivier > (installed a backported multiprocessing on his 2.5.1 Python, but need > installation of Xcode first) Mul

Re: Status of Python threading support (GIL removal)?

On 21 juin, 03:27, Jure Erznožnik wrote: > Add: > Carl, Olivier & co. - You guys know exactly what I wanted. > Others: Going back to C++ isn't what I had in mind when I started > initial testing for my project. Do you think multiprocessing can help you seriously ? Can you benefit from multiple cp

Re: Status of Python threading support (GIL removal)?

Look, guys, here's the thing: In the company I work at we decided to rewrite our MRP system in Python. I was one of the main proponents of it since it's nicely cross platform and allows for quite rapid application development. The language and it's built in functions are simply great. The oppositio

Re: Status of Python threading support (GIL removal)?

On Jun 20, 8:18 pm, s...@pobox.com wrote: >     Carl> Maybe you don't intend to sound like you're saying "shut up and >     Carl> use C", but to me, that's how you come off.  If you're going to >     Carl> advise someone to use C, at least try to show some understanding >     Carl> for their concer

Re: Status of Python threading support (GIL removal)?

On 20 Jun., 17:28, Stefan Behnel wrote: > Kay Schluehr wrote: > >> You might want to read about "The Problem with Threads": > > >>http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf > > >> and then decide to switch to an appropriate concurrency model for your use > >> case. > > > and t

Re: Status of Python threading support (GIL removal)?

Carl> I'm sure you think you're trying to be helpful, but you're coming Carl> off as really presumptuous with this casual dismissal of their Carl> concerns. My apologies, but in most cases there is more than one way to skin a cat. Trust me, if removing the global interpreter lock was

Re: Status of Python threading support (GIL removal)?

Add: Carl, Olivier & co. - You guys know exactly what I wanted. Others: Going back to C++ isn't what I had in mind when I started initial testing for my project. -- http://mail.python.org/mailman/listinfo/python-list

Re: Status of Python threading support (GIL removal)?

On Jun 20, 6:36 am, s...@pobox.com wrote: >     Carl> Here's the thing: not everyone complaining about the GIL is trying >     Carl> to get the "raw power of their machines."  They just want to take >     Carl> advantage of multiple cores so that their Python program runs >     Carl> faster. > > If

Re: Status of Python threading support (GIL removal)?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-Paul Calderone wrote: > On Sat, 20 Jun 2009 00:07:27 GMT, Lie Ryan wrote: >> [snip] >> >> Perhaps we should have more built-in/stdlib operations that can release >> GIL safely to release GIL by default? And perhaps some builtin/stdlib >> should r

Re: Status of Python threading support (GIL removal)?

Kay Schluehr wrote: >> You might want to read about "The Problem with Threads": >> >> http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf >> >> and then decide to switch to an appropriate concurrency model for your use >> case. > > and to a programming language that supports it. Maybe

Re: Status of Python threading support (GIL removal)?

Carl> Here's the thing: not everyone complaining about the GIL is trying Carl> to get the "raw power of their machines." They just want to take Carl> advantage of multiple cores so that their Python program runs Carl> faster. If their code is CPU-bound it's likely that rewriting

Re: Status of Python threading support (GIL removal)?

On 20 juin, 11:02, Carl Banks wrote: > Here's the thing: not everyone complaining about the GIL is trying to > get the "raw power of their machines."  They just want to take > advantage of multiple cores so that their Python program runs > faster. > > It would be rude and presumptuous to tell such

Re: Status of Python threading support (GIL removal)?

> You might want to read about "The Problem with Threads": > > http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf > > and then decide to switch to an appropriate concurrency model for your use > case. and to a programming language that supports it. -- http://mail.python.org/mailman/

Re: Status of Python threading support (GIL removal)?

On Jun 19, 4:35 pm, a...@pythoncraft.com (Aahz) wrote: > In article <157e0345-74e0-4144-a2e6-2b4cc854c...@z7g2000vbh.googlegroups.com>, > Carl Banks   wrote: > >I wish Pythonistas would be more willing to acknowledge the (few) > >drawbacks of the language (or implementation, in this case) instead o

Re: Status of Python threading support (GIL removal)?

On Jun 19, 4:42 pm, Christian Heimes wrote: > OdarR schrieb: > > > On 19 juin, 21:41, Carl Banks wrote: > >> He's saying that if your code involves extensions written in C that > >> release the GIL, the C thread can run on a different core than the > >> Python-thread at the same time.  The GIL is

Re: Status of Python threading support (GIL removal)?

> Ross Ridge (RR) wrote: >RR> By definition an I/O bound thread isn't CPU bound so won't benefit from >RR> improved CPU resources. But doing I/O is not the same as being I/O bound. And Python allows multithreading when a thread does I/O even if that thread is not I/O bound but CPU bound. See

Re: Status of Python threading support (GIL removal)?

> Jure Erznožnik (JE) wrote: >JE> I have shown my benchmarks. See first post and click on the link. >JE> That's the reason I started this discussion. >JE> All I'm saying is that you can get threading benefit, but only if the >JE> threading in question is implemented in C plugin. >JE> I have

Re: Status of Python threading support (GIL removal)?

> Jure Erznožnik (JE) wrote: >JE> Sorry, just a few more thoughts: >JE> Does anybody know why GIL can't be made more atomic? I mean, use >JE> different locks for different parts of code? >JE> This way there would be way less blocking and the plugin interface >JE> could remain the same (the in

Re: Status of Python threading support (GIL removal)?

On Sat, 20 Jun 2009 00:07:27 GMT, Lie Ryan wrote: [snip] Perhaps we should have more built-in/stdlib operations that can release GIL safely to release GIL by default? And perhaps some builtin/stdlib should receive an optional argument that instruct them to release GIL and by passing this argume

Re: Status of Python threading support (GIL removal)?

Jure Erznožnik wrote: > On Jun 20, 1:36 am, a...@pythoncraft.com (Aahz) wrote: >> You should put up or shut up -- I've certainly seen multi-core speedup >> with threaded software, so show us your benchmarks! >> -- > > Sorry, no intent to offend anyone here. Flame wars are not my thing. > > I have

Re: Status of Python threading support (GIL removal)?

Jesse Noller wrote: > Sorry, you're incorrect. I/O Bound threads do in fact, take advantage > of multiple cores. wrote: >Incorrect. They take advantage of OS threading support where another >thread can run while one is blocked for I/O. That is not equal to >running on multiple cores (though it

Re: Status of Python threading support (GIL removal)?

Aahz wrote: > In article <157e0345-74e0-4144-a2e6-2b4cc854c...@z7g2000vbh.googlegroups.com>, > Carl Banks wrote: >> I wish Pythonistas would be more willing to acknowledge the (few) >> drawbacks of the language (or implementation, in this case) instead of >> all this rationalization. > > Pleas

Re: Status of Python threading support (GIL removal)?

On Jun 20, 1:36 am, a...@pythoncraft.com (Aahz) wrote: > > You should put up or shut up -- I've certainly seen multi-core speedup > with threaded software, so show us your benchmarks! > -- Sorry, no intent to offend anyone here. Flame wars are not my thing. I have shown my benchmarks. See first p

Re: Status of Python threading support (GIL removal)?

OdarR schrieb: > On 19 juin, 21:41, Carl Banks wrote: >> He's saying that if your code involves extensions written in C that >> release the GIL, the C thread can run on a different core than the >> Python-thread at the same time. The GIL is only required for Python >> code, and C code that uses t

Re: Status of Python threading support (GIL removal)?

In article , =?windows-1252?Q?Jure_Erzno=9Enik?= wrote: >On Jun 19, 11:59=A0pm, Jesse Noller wrote: >> >> Sorry, you're incorrect. I/O Bound threads do in fact, take advantage >> of multiple cores. > >Incorrect. They take advantage of OS threading support where another >thread can run while one

Re: Status of Python threading support (GIL removal)?

In article <157e0345-74e0-4144-a2e6-2b4cc854c...@z7g2000vbh.googlegroups.com>, Carl Banks wrote: > >I wish Pythonistas would be more willing to acknowledge the (few) >drawbacks of the language (or implementation, in this case) instead of >all this rationalization. Please provide more evidence

Re: Status of Python threading support (GIL removal)?

In article , =?windows-1252?Q?Jure_Erzno=9Enik?= wrote: > >I do aggree though that threading is important. Regardless of any >studies showing that threads suck, they are here and they offer >relatively simple concurrency. IMHO they should never have been >crippled like this. Even though GIL solve

Re: Status of Python threading support (GIL removal)?

On Fri, Jun 19, 2009 at 6:10 PM, Jure Erznožnik wrote: > On Jun 19, 11:59 pm, Jesse Noller wrote: >> On Fri, Jun 19, 2009 at 12:50 PM, OdarR wrote: >> > On 19 juin, 16:16, Martin von Loewis > >> If you know that your (C) code is thread safe on its own, you can >> >> release the GIL around long-run

Re: Status of Python threading support (GIL removal)?

On 19 Jun, 21:41, Carl Banks wrote: > > (Note: I'm not talking about releasing the GIL for I/O operations, > it's not the same thing.  I'm talking about the ability to run > computations on multiple cores at the same time, not to block in 50 > threads at the same time.  Multiple cores aren't going

Re: Status of Python threading support (GIL removal)?

On Jun 19, 11:59 pm, Jesse Noller wrote: > On Fri, Jun 19, 2009 at 12:50 PM, OdarR wrote: > > On 19 juin, 16:16, Martin von Loewis >> If you know that your (C) code is thread safe on its own, you can > >> release the GIL around long-running algorithms, thus using as many > >> CPUs as you have ava

Re: Status of Python threading support (GIL removal)?

On Jun 19, 11:45 pm, OdarR wrote: > On 19 juin, 21:05, Christian Heimes wrote: > > > I've seen a single Python process using the full capacity of up to 8 > > CPUs. The application is making heavy use of lxml for large XSL > > transformations, a database adapter and my own image processing library

Re: Status of Python threading support (GIL removal)?

On Fri, Jun 19, 2009 at 12:50 PM, OdarR wrote: > On 19 juin, 16:16, Martin von Loewis > If you know that your (C) code is thread safe on its own, you can >> release the GIL around long-running algorithms, thus using as many >> CPUs as you have available, in a single process. > > what do you mean ?

Re: Status of Python threading support (GIL removal)?

On 19 juin, 21:41, Carl Banks wrote: > He's saying that if your code involves extensions written in C that > release the GIL, the C thread can run on a different core than the > Python-thread at the same time.  The GIL is only required for Python > code, and C code that uses the Python API.  C cod

Re: Status of Python threading support (GIL removal)?

Sorry, just a few more thoughts: Does anybody know why GIL can't be made more atomic? I mean, use different locks for different parts of code? This way there would be way less blocking and the plugin interface could remain the same (the interpreter would know what lock it used for the plugin, so t

Re: Status of Python threading support (GIL removal)?

On 19 juin, 21:05, Christian Heimes wrote: > I've seen a single Python process using the full capacity of up to 8 > CPUs. The application is making heavy use of lxml for large XSL > transformations, a database adapter and my own image processing library > based upon FreeImage. interesting... > O

Re: Status of Python threading support (GIL removal)?

Thanks guys, for all the replies. They were some very interesting reading / watching. Seems to me, the Unladen-Swallow might in time produce code which will have this problem lessened a bit. Their roadmap suggests at least modifying the GIL principles if not fully removing it. On top of this, they

Re: Status of Python threading support (GIL removal)?

On Jun 19, 11:08 am, OdarR wrote: > On 19 juin, 19:13, s...@pobox.com wrote: > > >     Olivier> what do you mean ? > > >     Olivier> Cpython can't benefit from multi-core without multiple > >     Olivier> processes. > > > It can, precisely as Martin indicated.  Only one thread at a time can hold

Re: Status of Python threading support (GIL removal)?

On Jun 19, 6:53 am, Ben Charrow wrote: > Jure Erznožnik wrote: > > See here for introduction: > >http://groups.google.si/group/comp.lang.python/browse_thread/thread/3... > > > Digging through my problem, I discovered Python isn't exactly thread > > safe and to solve the issue, there's this Global

Re: Status of Python threading support (GIL removal)?

OdarR wrote: > I don't see such improvement in the Python library, or maybe you can > indicate us some meaningfull example...? > > I currently only use CPython, with PIL, Reportlab...etc. > I don't see improvement on a Core2duo CPU and Python. How to proceed > (following what you wrote) ? I've se

Re: Status of Python threading support (GIL removal)?

On 19 juin, 19:13, s...@pobox.com wrote: >     Olivier> what do you mean ? > >     Olivier> Cpython can't benefit from multi-core without multiple >     Olivier> processes. > > It can, precisely as Martin indicated.  Only one thread at a time can hold > the GIL.  That doesn't mean that multiple thr

Re: Status of Python threading support (GIL removal)?

>> If you know that your (C) code is thread safe on its own, you can >> release the GIL around long-running algorithms, thus using as many >> CPUs as you have available, in a single process. Olivier> what do you mean ? Olivier> Cpython can't benefit from multi-core without mu

Re: Status of Python threading support (GIL removal)?

CPython itself can't... but the c extension can. Mine did. On Fri, Jun 19, 2009 at 9:50 AM, OdarR wrote: > On 19 juin, 16:16, Martin von Loewis > If you know that your (C) code is thread safe on its own, you can > > release the GIL around long-running algorithms, thus using as many > > CPUs as

Re: Status of Python threading support (GIL removal)?

On 19 juin, 16:16, Martin von Loewis If you know that your (C) code is thread safe on its own, you can > release the GIL around long-running algorithms, thus using as many > CPUs as you have available, in a single process. what do you mean ? Cpython can't benefit from multi-core without multiple

Re: Status of Python threading support (GIL removal)?

Jure Erznožnik wrote: See here for introduction: http://groups.google.si/group/comp.lang.python/browse_thread/thread/370f8a1747f0fb91 Digging through my problem, I discovered Python isn't exactly thread safe and to solve the issue, there's this Global Interpreter Lock (GIL) in place. Effectively

Re: Status of Python threading support (GIL removal)?

Jure Erznožnik wrote: > See here for introduction: > http://groups.google.si/group/comp.lang.python/browse_thread/thread/370f8a1747f0fb91 > > Digging through my problem, I discovered Python isn't exactly thread > safe and to solve the issue, there's this Global Interpreter Lock > (GIL) in place. >

Re: Status of Python threading support (GIL removal)?

On 19 juin, 11:52, Jure Erznožnik wrote: > See here for > introduction:http://groups.google.si/group/comp.lang.python/browse_thread/thread/3... > > Digging through my problem, I discovered Python isn't exactly thread > safe and to solve the issue, there's this Global Interpreter Lock > (GIL) in p

Re: Status of Python threading support (GIL removal)?

Digging through my problem, I discovered Python isn't exactly thread safe and to solve the issue, there's this Global Interpreter Lock (GIL) in place. It's the opposite: Python is exactly thread safe precisely because it has the GIL in place. Is there any other way to work around the issue asi

Re: Status of Python threading support (GIL removal)?

Digging through my problem, I discovered Python isn't exactly thread safe and to solve the issue, there's this Global Interpreter Lock (GIL) in place. It's the opposite: Python is exactly thread safe precisely because it has the GIL in place. Is there any other way to work around the issue asi

Re: Status of Python threading support (GIL removal)?

Jure Erznožnik wrote: > See here for introduction: > http://groups.google.si/group/comp.lang.python/browse_thread/thread/370f8a1747f0fb91 > > Digging through my problem, I discovered Python isn't exactly thread > safe and to solve the issue, there's this Global Interpreter Lock > (GIL) in place. >

Re: Status of Python threading support (GIL removal)?

This is a very long-running issue, that has been discussed many times. Here are the two sides to keeping the gil or removing it: Remove the GIL: - True multi-threaded programming - Scalable performance across a multi-core machine - Unfortunately, this causes a slow-down in single core/th

Status of Python threading support (GIL removal)?

See here for introduction: http://groups.google.si/group/comp.lang.python/browse_thread/thread/370f8a1747f0fb91 Digging through my problem, I discovered Python isn't exactly thread safe and to solve the issue, there's this Global Interpreter Lock (GIL) in place. Effectively, this causes the interp

Python threading

I'm doing some multi-threaded programming and before diving into the C/C++ code I though I'd do some in Python first. I decided to read through the threading module and I understand some of it, but I don't understand this, though I'm sure it is easy: The condition object has a method _is_owne

Re: Python, threading

In article , SMALLp wrote: > >Hy. I have a problem! I'm making multi thread application (client, >server) using wxPython for GUI, and threading.Thread for threding. > >Clients connect and when they are connected (evry thread handles one >connection) threads change main window. > >I neded tip ho

Re: Python, threading

SMALLp wrote: ... I need a tip on how to communicat4 between threads. Typically inter-thread communication is done via Queue.Queue. Look up the Queue module in your docs. a "Simple" example: import Queue shared_work = Queue.Queue() combined_replies = Queue.Queue() ... [distribu

Re: Python, threading

On 2008-12-11, SMALLp <[EMAIL PROTECTED]> wrote: > Hy. I have a problem! I'm making multi thread application (client, > server) using wxPython for GUI, and threading.Thread for threding. > > Clients connect and when they are connected (evry thread handles one > connection) threads change main win

Re: Python, threading

SMALLp wrote: > Hy. I have a problem! I'm making multi thread application (client, > server) using wxPython for GUI, and threading.Thread for threding. > > Clients connect and when they are connected (evry thread handles one > connection) threads change main window. > > I neded tip how to make c

Re: Python, threading

On Dec 11, 6:06 pm, SMALLp <[EMAIL PROTECTED]> wrote: > Hy. I have a problem! I'm making multi thread application (client, > server) using wxPython for GUI, and threading.Thread for threding. > > Clients connect and when they are connected (evry thread handles one > connection) threads change main

Python, threading

Hy. I have a problem! I'm making multi thread application (client, server) using wxPython for GUI, and threading.Thread for threding. Clients connect and when they are connected (evry thread handles one connection) threads change main window. I neded tip how to make communication between thre

Re: What is wrong with my Python threading?

On Tue, May 20, 2008 at 4:28 PM, castironpi <[EMAIL PROTECTED]> wrote: > On May 20, 8:19 am, "Chuckk Hubbard" <[EMAIL PROTECTED]> > wrote: >> #!/usr/bin/python >> >> #why doesn't this run both threads simultaneously? >> #Thanks for any help. >> #Chuckk >> >> import threading >> import time >> >> de

Re: What is wrong with my Python threading?

On Tue, May 20, 2008 at 8:24 PM, Gabriel Genellina <[EMAIL PROTECTED]> wrote: > En Tue, 20 May 2008 10:28:51 -0300, castironpi <[EMAIL PROTECTED]> > escribió: > >> You meant 'thd1.start( )' and 'thd2.start( )'. > > Wow! A message with a high S/N ratio coming from you! > And it's not the first I've

  1   2   >