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
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
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
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
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
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
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:
>>
>>
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
On 8/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I am using the threading module and the Queue module in python to to
> send out shipment tracking URL requests.
>
> Is there a way to timeout a thread within a Queue?
>
> I think the way I have it now the thread will wait until s
En Fri, 09 Mar 2007 00:38:55 -0300, <[EMAIL PROTECTED]> escribió:
> pythoncom.CoUninitialize(), if I am not mistaken, releases a COM
> object (and therefore the memory it uses I assume).
Not exactly. *You* must release the COM object (usually assigning None to
all references to it). CoUninitial
On Mar 8, 6:15 pm, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote:
> En Thu, 08 Mar 2007 14:25:02 -0300, <[EMAIL PROTECTED]> escribió:
> All threads share the same memory space, there is not a "per-thread"
> memory allocator, if that's what you are thinking.
> Perhaps you hold a reference to some ob
En Thu, 08 Mar 2007 14:25:02 -0300, <[EMAIL PROTECTED]> escribió:
> I am wondering what happens to a thread in python in relation to
> win32com extensions.
>
> If I create a new thread, that uses the Dispatch method from win32com,
> what happens to the memory allocated in that thread when the thre
Renato wrote:
> Dear all,
>
> I found this nifty article on how to record your favourite radio show
> using cron and mplayer:
> http://grimthing.com/archives/2004/05/20/recording-streaming-audio-with-mplayer/
>
> Because I couldn't get the date in the filename (and was too lazy to
> look into sh/b
In article <[EMAIL PROTECTED]>,
Laurent Pointal <[EMAIL PROTECTED]> wrote:
.
.
.
>May use Python for some -non realtime- parts, but I would not use any
>scripting language (not specific to Python) for real-time work (prefer
>C
Dennis Lee Bieber a écrit :
> On Sun, 1 Oct 2006 22:28:10 +0200, "Oeyvind Brandtsegg"
> <[EMAIL PROTECTED]> declaimed the following in comp.lang.python:
>
>> Also, I wonder what method I should be using to get a precise timing
>> in my automation thread (acting as a sequencer).
>>
> Use a re
daniel wrote:
> Can anyone explain the main points in working with threads in Python.
They are system threads, so the main points are much like in
other languages. Examine how thread.lock works, and look up the
queue module.
> Why use threading and not Thread.
There's no reason not to use thread
Calvin Spealman wrote:
> I repeat this all the time, but the best advice I can give you about
> using threads is to not use threads at all.
Might as well get with the times and ignore that advice.
> I would point you to good
> references like Threads Considered Harmful
> (http://www.kuro5hin.org/
Dennis Lee Bieber wrote:
> ... slightly
> simpler to use without subclassing (at the simplest level, you just pass
> the function that is to be run, and a list of the arguments/parameters
> it needs, to the threading creation class).
that's exactly how thread.start_new_thread(func, args) works, o
On 20 Sep 2006 00:27:07 -0700, daniel <[EMAIL PROTECTED]> wrote:
> Hello,
> Can anyone explain the main points in working with threads in Python.
> Why use threading and not Thread.I have read an article that i have to
> subclass the Thread class and override some function.
I repeat this all the t
daniel <[EMAIL PROTECTED]> wrote:
> can someone give me a good threading tutorial
http://awaretek.com/tutorials.html#thread
and
http://www.google.com/search?q=python+threading+tutorial
--
Lawrence - http://www.oluyede.org/blog
"Nothing is more dangerous than an idea
if it's the only one you have
Robin Haswell wrote:
> Hey there
>
> I'm doing some threading in python with Python 2.3 and 2.4 on Ubuntu and
> Debian machines, and I've noticed that if I open a lot of threads (say,
> 50), I get lots of python processes with individual PIDs, which consume a
> disproportionate amount of CPU. Does
Robin Haswell <[EMAIL PROTECTED]> wrote:
...
> Cheers for that info. The thread's main tasks are getting webpages
> (spidering), the actual amount of processing done in each thread is
> minimal - that's why I'm confused by the CPU usage.
BTW, spidering is a great use case for async (even-driven
On Wed, 08 Feb 2006 14:24:38 +0100, Diez B. Roggisch wrote:
> Robin Haswell wrote:
>
>> Hey there
>>
>> I'm doing some threading in python with Python 2.3 and 2.4 on Ubuntu and
>> Debian machines, and I've noticed that if I open a lot of threads (say,
>> 50), I get lots of python processes with
Robin Haswell wrote:
> Hey there
>
> I'm doing some threading in python with Python 2.3 and 2.4 on Ubuntu and
> Debian machines, and I've noticed that if I open a lot of threads (say,
> 50), I get lots of python processes with individual PIDs, which consume a
> disproportionate amount of CPU. Doe
47 matches
Mail list logo
