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
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
20 matches
Mail list logo
