Re: Thread-safe way to add a key to a dict only if it isn't already there?

Chris Angelico : > On Mon, Jul 9, 2018 at 5:18 AM, Marko Rauhamaa wrote: >> Chris Angelico : >>> Are you assuming that Python's semantics are defined by the semantics >>> of one possible implementation language? >> >> What are Python's semantics defined by? I've been using these: >> >>https:/

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Mon, Jul 9, 2018 at 5:18 AM, Marko Rauhamaa wrote: > Chris Angelico : >> Are you assuming that Python's semantics are defined by the semantics >> of one possible implementation language? > > What are Python's semantics defined by? I've been using these: > >https://docs.python.org/3/referenc

Re: Thread-safe way to add a key to a dict only if it isn't already there?

Chris Angelico : > Are you assuming that Python's semantics are defined by the semantics > of one possible implementation language? What are Python's semantics defined by? I've been using these: https://docs.python.org/3/reference/> https://docs.python.org/3/library/> Unfortunately, neith

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Mon, Jul 9, 2018 at 4:57 AM, Marko Rauhamaa wrote: > Chris Angelico : > >> On Mon, Jul 9, 2018 at 2:11 AM, Marko Rauhamaa wrote: >>> MRAB : In C you'd declare 'quit' as 'volatile' to tell the compiler that it could change unexpectedly, so don't make that assumption. >>> >>> C is an e

Re: Thread-safe way to add a key to a dict only if it isn't already there?

Chris Angelico : > On Mon, Jul 9, 2018 at 2:11 AM, Marko Rauhamaa wrote: >> MRAB : >>> In C you'd declare 'quit' as 'volatile' to tell the compiler that it >>> could change unexpectedly, so don't make that assumption. >> >> C is an even tougher case. Even if the compiler kept on checking a >> vol

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Sun, 08 Jul 2018 16:37:11 +0100, MRAB wrote: > On 2018-07-08 14:38, Steven D'Aprano wrote: >> On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: >> > [snip] >>> More importantly, this loop may never finish: >>> >>> # Initially >>> quit = False >>> >>> # Thread 1 >>> gl

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Sun, 08 Jul 2018 19:35:55 +0300, Marko Rauhamaa wrote: > Steven D'Aprano : >> On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: >>> PS My example with "impossible" being the result of a racy integer >>> operation is of course unlikely but could be the outcome if the Python >>> runtime r

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Mon, Jul 9, 2018 at 2:11 AM, Marko Rauhamaa wrote: > MRAB : >> On 2018-07-08 14:38, Steven D'Aprano wrote: >>> On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: >>> >> [snip] More importantly, this loop may never finish: # Initially quit = False

Re: Thread-safe way to add a key to a dict only if it isn't already there?

Steven D'Aprano : > On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: >> PS My example with "impossible" being the result of a racy integer >> operation is of course unlikely but could be the outcome if the Python >> runtime reorganized its object cache on the fly (in a hypothetical >> impl

Re: Thread-safe way to add a key to a dict only if it isn't already there?

MRAB : > On 2018-07-08 14:38, Steven D'Aprano wrote: >> On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: >> > [snip] >>> More importantly, this loop may never finish: >>> >>> # Initially >>> quit = False >>> >>> # Thread 1 >>> global quit >>> while not quit: >>>

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On 2018-07-08 14:38, Steven D'Aprano wrote: On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: [snip] More importantly, this loop may never finish: # Initially quit = False # Thread 1 global quit while not quit: time.sleep(1) # Thread 2 global quit

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: > Steven D'Aprano : >> Changing implementations from one which is thread safe to one which is >> not can break people's code, and shouldn't be done on a whim. >> Especially since such breakage could be subtle, hard to notice, harder >> to t

Re: Thread-safe way to add a key to a dict only if it isn't already there?

Steven D'Aprano : > Changing implementations from one which is thread safe to one which is > not can break people's code, and shouldn't be done on a whim. > Especially since such breakage could be subtle, hard to notice, harder > to track down, and even harder still to fix. Java's HotSpot does it

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Sun, 08 Jul 2018 10:52:15 +0300, Marko Rauhamaa wrote: > You are on the right track, Chris, but you are still deducing behavior > from a particular implementation. For example Java's definition is > approximately the one I give above: > >Without correct synchronization, very strange, confu

Re: Thread-safe way to add a key to a dict only if it isn't already there?

Chris Angelico : > On Sun, Jul 8, 2018 at 11:04 AM, Steven D'Aprano > wrote: >>> The only thing Python should guarantee is that the data structures stay >>> "coherent" under race conditions. In other words, there cannot be a >>> segmentation fault. For example, if two threads executed this code i

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Sun, Jul 8, 2018 at 1:58 PM, Steven D'Aprano wrote: > On Sun, 08 Jul 2018 12:23:41 +1000, Chris Angelico wrote: > >>> Some people, when confronted with a problem, say, "I know, I'll use >>> threads". Nothhtwo probw ey ave lems. >> >> Right. Now they have to deal with interleaving, but that's al

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Sun, 08 Jul 2018 12:23:41 +1000, Chris Angelico wrote: >> Some people, when confronted with a problem, say, "I know, I'll use >> threads". Nothhtwo probw ey ave lems. > > Right. Now they have to deal with interleaving, but that's all. And > honestly, MOST CODE wouldn't notice interleaving; it'

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Sun, Jul 8, 2018 at 12:12 PM, Steven D'Aprano wrote: > On Sun, 08 Jul 2018 11:15:17 +1000, Chris Angelico wrote: > > [...] >> Python threads don't switch only between lines of code, > > As I understand it, there could be a switch between any two byte codes, > or maybe only between certain bytes

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Sun, 08 Jul 2018 11:15:17 +1000, Chris Angelico wrote: [...] > Python threads don't switch only between lines of code, As I understand it, there could be a switch between any two byte codes, or maybe only between certain bytes codes. But certain more fine grained than just between lines of

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Sun, Jul 8, 2018 at 11:04 AM, Steven D'Aprano wrote: >> The only thing Python should guarantee is that the data structures stay >> "coherent" under race conditions. In other words, there cannot be a >> segmentation fault. For example, if two threads executed this code in >> parallel: >> >>

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Sun, 08 Jul 2018 00:00:26 +0300, Marko Rauhamaa wrote: > Ian Kelly : >> the leaning of the devs seems to be to refrain from documenting it and >> instead document that *no* operations are guaranteed atomic. > > I believe that to be wise. Otherwise, Python would limit its future > implementatio

Re: Thread-safe way to add a key to a dict only if it isn't already there?

Ian Kelly : > the leaning of the devs seems to be to refrain from documenting it and > instead document that *no* operations are guaranteed atomic. I believe that to be wise. Otherwise, Python would limit its future implementation options. The only thing Python should guarantee is that the data s

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On 07/06/2018 10:51 AM, INADA Naoki wrote: > On Sat, Jul 7, 2018 at 2:49 AM Steven D'Aprano wrote: >> I have a dict with string keys: >> >> --> D = {'a': None, 'b': None} >> How do I do a thread-safe insertion if, and only if, the key isn't >> already there? > D.setdefault('c', None) This is

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Fri, Jul 6, 2018 at 11:56 AM INADA Naoki wrote: > > D.setdefault('c', None) Not guaranteed to be atomic. I think the only safe way to do it is with a Lock. -- https://mail.python.org/mailman/listinfo/python-list

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Sat, Jul 7, 2018 at 6:49 AM Marko Rauhamaa wrote: > Is that guaranteed to be thread-safe? The documentation ( s://docs.python.org/3/library/stdtypes.html#dict.setdefault>) makes no > such promise. It's guaranteed to be thread-safe because all of Python's core containers are thread safe (in as

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Sat, Jul 7, 2018 at 8:03 AM Stefan Behnel wrote: > > Marko Rauhamaa schrieb am 07.07.2018 um 15:41: > > Steven D'Aprano : > >> On Sat, 07 Jul 2018 02:51:41 +0900, INADA Naoki wrote: > >>> D.setdefault('c', None) > >> > >> Oh that's clever! > > > > Is that guaranteed to be thread-safe? The docum

Re: Thread-safe way to add a key to a dict only if it isn't already there?

Marko Rauhamaa schrieb am 07.07.2018 um 15:41: > Steven D'Aprano : >> On Sat, 07 Jul 2018 02:51:41 +0900, INADA Naoki wrote: >>> D.setdefault('c', None) >> >> Oh that's clever! > > Is that guaranteed to be thread-safe? The documentation ( s://docs.python.org/3/library/stdtypes.html#dict.setdefault

Re: Thread-safe way to add a key to a dict only if it isn't already there?

Steven D'Aprano : > On Sat, 07 Jul 2018 02:51:41 +0900, INADA Naoki wrote: >> D.setdefault('c', None) > > Oh that's clever! Is that guaranteed to be thread-safe? The documentation () makes no such promise. At least __collectios_abc.py contains this method definition for MutableMapping: def s

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Sat, 07 Jul 2018 02:51:41 +0900, INADA Naoki wrote: > D.setdefault('c', None) Oh that's clever! Thanks! -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list

Re: Thread-safe way to add a key to a dict only if it isn't already there?

D.setdefault('c', None) On Sat, Jul 7, 2018 at 2:49 AM Steven D'Aprano wrote: > > I have a dict with string keys: > > D = {'a': None, 'b': None} > > (the values don't matter for this question) and I want to add a key but > only if it isn't already there. If I do the obvious: > > if not 'c' in D: >

Re: Thread safety issue (I think) with defaultdict

On Sat, 4 Nov 2017 05:12 am, Israel Brewster wrote: [...] >> People generally understand how to move data around, and the mistakes are >> usually pretty obvious when they happen. > > I think the existence of this thread indicates otherwise :-) This mistake > was far from obvious, and clearly I di

Re: Thread safety issue (I think) with defaultdict

On 03/11/17 18:12, Israel Brewster wrote: On Nov 3, 2017, at 7:11 AM, Rhodri James wrote: People generally understand how to move data around, and the mistakes are usually pretty obvious when they happen. I think the existence of this thread indicates otherwise :-) This mistake was far from

Re: Thread safety issue (I think) with defaultdict

--- Israel Brewster Systems Analyst II Ravn Alaska 5245 Airport Industrial Rd Fairbanks, AK 99709 (907) 450-7293 --- > On Nov 3, 2017, at 7:11 AM, Rhodri James wrote: > > On 03/11/17 14:50, Chris Angelico

Re: Thread safety issue (I think) with defaultdict

On Friday 03 November 2017 10:50:13 Chris Angelico wrote: > On Fri, Nov 3, 2017 at 10:26 PM, Rhodri James wrote: > > On 02/11/17 20:24, Chris Angelico wrote: > >> Thank you. I've had this argument with many people, smart people > >> (like Steven), people who haven't grokked that all concurrency

Re: Thread safety issue (I think) with defaultdict

On Thu, Nov 2, 2017 at 10:27 AM, Israel Brewster wrote: > >> On Nov 1, 2017, at 4:53 PM, Steve D'Aprano >> wrote: >> >> On Thu, 2 Nov 2017 05:53 am, Israel Brewster wrote: >> >> [...] >>> So the end result is that the thread that "updates" the dictionary, and the >>> thread that initially *popul

Re: Thread safety issue (I think) with defaultdict

On 2017-11-03, Chris Angelico wrote: > On Sat, Nov 4, 2017 at 2:45 AM, Steve D'Aprano > wrote: >> So, all else being equal, which is likely to have more bugs? >> >> >> 1. Multiprocessing code with very little coupling between processes; or >> >> 2. Threaded code with shared data and hence higher c

Re: Thread safety issue (I think) with defaultdict

On Sat, Nov 4, 2017 at 2:45 AM, Steve D'Aprano wrote: > So, all else being equal, which is likely to have more bugs? > > > 1. Multiprocessing code with very little coupling between processes; or > > 2. Threaded code with shared data and hence higher coupling between threads? > Obviously, option 1

Re: Thread safety issue (I think) with defaultdict

On Sat, 4 Nov 2017 01:50 am, Chris Angelico wrote: > On Fri, Nov 3, 2017 at 10:26 PM, Rhodri James wrote: >> I'm with Steven. To be fair, the danger with threads is that most people >> don't understand thread-safety, and in particular don't understand either >> that they have a responsibility t

Re: Thread safety issue (I think) with defaultdict

On 03/11/17 14:50, Chris Angelico wrote: On Fri, Nov 3, 2017 at 10:26 PM, Rhodri James wrote: On 02/11/17 20:24, Chris Angelico wrote: Thank you. I've had this argument with many people, smart people (like Steven), people who haven't grokked that all concurrency has costs - that threads aren'

Re: Thread safety issue (I think) with defaultdict

On Fri, Nov 3, 2017 at 10:26 PM, Rhodri James wrote: > On 02/11/17 20:24, Chris Angelico wrote: >> >> Thank you. I've had this argument with many people, smart people (like >> Steven), people who haven't grokked that all concurrency has costs - >> that threads aren't magically more dangerous than

Re: Thread safety issue (I think) with defaultdict

On 02/11/17 20:24, Chris Angelico wrote: Thank you. I've had this argument with many people, smart people (like Steven), people who haven't grokked that all concurrency has costs - that threads aren't magically more dangerous than other options. I'm with Steven. To be fair, the danger with thr

Re: Thread safety issue (I think) with defaultdict

On Fri, 3 Nov 2017 02:32 pm, Stefan Ram wrote: > Here is an excerpt from a text from Edward E. Lee: > > A part of the Ptolemy Project experiment was to see > whether effective software engineering practices could be > developed for an academic research setting. [...] > No problems were observed

Re: Thread safety issue (I think) with defaultdict

On Fri, 3 Nov 2017 02:19 pm, Rustom Mody wrote: > «The world is concurrent» [Joe Armstrong creator of Erlang] And the world is extremely complex, complicated and hard to understand. The point of programming is to simplify the world, not emulate it in its full complexity. -- Steve “Cheer up,

Re: Thread safety issue (I think) with defaultdict

On Friday, November 3, 2017 at 6:28:28 AM UTC+5:30, Steve D'Aprano wrote: > On Fri, 3 Nov 2017 07:24 am, Chris Angelico wrote: > > > On Fri, Nov 3, 2017 at 3:27 AM, Israel Brewster wrote: > >> > >> Actually, that saying is about regular expressions, not threads :-) . In > >> the end, threads are a

Re: Thread safety issue (I think) with defaultdict

On Fri, 3 Nov 2017 07:24 am, Chris Angelico wrote: > On Fri, Nov 3, 2017 at 3:27 AM, Israel Brewster > wrote: >> >> Actually, that saying is about regular expressions, not threads :-) . In >> the end, threads are as good a way as handling concurrency as any other, >> and simpler than many. They h

Re: Thread safety issue (I think) with defaultdict

On Fri, Nov 3, 2017 at 3:27 AM, Israel Brewster wrote: > > Actually, that saying is about regular expressions, not threads :-) . In the > end, threads are as good a way as handling concurrency as any other, and > simpler than many. They have their drawbacks, of course, mainly in the area > of o

Re: Thread safety issue (I think) with defaultdict

> On Nov 1, 2017, at 4:53 PM, Steve D'Aprano wrote: > > On Thu, 2 Nov 2017 05:53 am, Israel Brewster wrote: > > [...] >> So the end result is that the thread that "updates" the dictionary, and the >> thread that initially *populates* the dictionary are actually running in >> different processes

Re: Thread safety issue (I think) with defaultdict

On Thu, 2 Nov 2017 05:53 am, Israel Brewster wrote: [...] > So the end result is that the thread that "updates" the dictionary, and the > thread that initially *populates* the dictionary are actually running in > different processes. If they are in different processes, that would explain why the

Re: Thread safety issue (I think) with defaultdict

On Nov 1, 2017, at 9:58 AM, Ian Kelly wrote: > > On Tue, Oct 31, 2017 at 11:38 AM, Israel Brewster > wrote: >> A question that has arisen before (for example, here: >> https://mail.python.org/pipermail/python-list/2010-January/565497.html >>

Re: Thread safety issue (I think) with defaultdict

On Tue, Oct 31, 2017 at 11:38 AM, Israel Brewster wrote: > A question that has arisen before (for example, here: > https://mail.python.org/pipermail/python-list/2010-January/565497.html > ) is > the question of "is defaultd

Re: Thread safety issue (I think) with defaultdict

On Nov 1, 2017, at 9:04 AM, Israel Brewster wrote: > > Let me rephrase the question, see if I can simplify it. I need to be able to > access a defaultdict from two different threads - one thread that responds to > user requests which will populate the dictionary in response to a user > request

Re: Thread safety issue (I think) with defaultdict

Let me rephrase the question, see if I can simplify it. I need to be able to access a defaultdict from two different threads - one thread that responds to user requests which will populate the dictionary in response to a user request, and a second thread that will keep the dictionary updated as

Re: Thread getting stuck\hang

Hi Dennis, My requirement is like,i want to send the static and dynamic traffic together.while traffic sending i want to delete some config from device. st and dy both the targets want to be run at the same time. On Fri, Apr 28, 2017 at 6:10 PM, Dennis Lee Bieber wrote: > On Fri, 28 Apr 20

Re: Thread getting stuck\hang

Hi Dennis, Two threads(_st and _dy targets) sharing the same user define function at the same time...This is the reason for hang/stuck? in both the thread ,we are calling same user define function (itgen_explorer.startTrafficFlows) and greping the values from return function ,using it in main fu

Re: Thread getting stuck\hang

Hi Dennis, Two threads(_st and _dy targets) sharing the same user define function at the same time...This is the reason for hang/stuck? in both the thread ,we are calling same user define function (itgen_explorer.startTrafficFlows) and greping the values from return function ,using it in main fu

Re: Thread getting stuck\hang

Thanks Dennis, On Fri, Apr 28, 2017 at 5:06 AM, Dennis Lee Bieber wrote: > On Thu, 27 Apr 2017 22:16:06 +0530, Iranna Mathapati > declaimed the following: > > >Hi Dennis, > > > >all function arguments declare as global and pass it to the function. > > > >All three thread is completed the execut

Re: Thread getting stuck\hang

Hi Dennis, all function arguments declare as global and pass it to the function. All three thread is completed the execution part and after completion of execution its stuck/hang the programme. *def validate_traffic_stats_st(FT_item,RT_item,forward_path_list,return_path_list,nat_type_list,pkt_st

Re: Thread within for loop

Iranna Mathapati writes: > How to fix it and now i got below error for same script Fixing "timeout" problems is (usually) not a Python question. A "timeout" can have various reasons: * you make something fundamentally wrong - i.e. try to connect to something which is inaccessible (e.g. by "

Re: Thread within for loop

Hi , How to fix it and now i got below error for same script *runtimeerror threads can only be started once then* *Thanks,* On Sat, Apr 1, 2017 at 1:15 PM, dieter wrote: > Iranna Mathapati writes: > > ... > > Exception in thread Thread-5: > > Traceback (most recent call last): > > ... > >

Re: Thread within for loop

Iranna Mathapati writes: > ... > Exception in thread Thread-5: > Traceback (most recent call last): > ... > File > "/auto/n3k-qa/CODC/ianandan/pyATS2.7/lib/python2.7/site-packages/pexpect/__init__.py", > line 1466, in expect_list > timeout, searchwindowsize) > File > "/auto/n3k-qa/CODC/ian

Re: Thread-ID - how much could be?

Am 11.09.2014 23:32 schrieb Ervin Hegedüs: There is no upper limit to the thread name other than that you will eventually run out of memory ;) thanks - I hope that the memory will not run out by these threads... :) Anyway, that means, on my system: import sys print sys.maxint 9223372036854

Re: Thread-ID - how much could be?

On Sat, Sep 13, 2014 at 12:09:28PM +0200, Martin Skjöldebrand wrote: > Unfortunately we will never know 😢 hehe :), joke of the day :) thanks, a. -- I � UTF-8 -- https://mail.python.org/mailman/listinfo/python-list

Re: Thread-ID - how much could be?

Unfortunately we will never know 😢 Sent from Blue Mail On 12 Sep 2014 07:43, at 07:43, Chris Angelico wrote: >On Fri, Sep 12, 2014 at 1:41 PM, Cameron Simpson wrote: >> On 12Sep2014 11:29, Steven D'Aprano > >> wrote: >>> >>> [...]maxint. I know that some Linux >>> systems can have an uptime o

Re: Thread-ID - how much could be?

dieter wrote: > Ervin Hegedüs writes: >> ... > What is used as thread id is platform dependent. Likely, it depends > on the thread support of the underlying C libary (i.e. the > operating system thread support). > > Under Linux, thread ids seem to be addresses - i.e. very large > integers. $ gr

Re: Thread-ID - how much could be?

Ervin Hegedüs writes: > ... What is used as thread id is platform dependent. Likely, it depends on the thread support of the underlying C libary (i.e. the operating system thread support). Under Linux, thread ids seem to be addresses - i.e. very large integers. -- https://mail.python.org/mailma

Re: Thread-ID - how much could be?

Hi Steven, On Fri, Sep 12, 2014 at 11:29:56AM +1000, Steven D'Aprano wrote: > import sys > print sys.maxint > > 9223372036854775807 > > > > the couter could be 9223372036854775807? > > > > And after? :) > > Suppose you somehow managed to create 9223372036854775807 threads. If your > c

Re: Thread-ID - how much could be?

On Fri, Sep 12, 2014 at 1:41 PM, Cameron Simpson wrote: > On 12Sep2014 11:29, Steven D'Aprano > wrote: >> >> [...]maxint. I know that some Linux >> systems can have an uptime over a year, perhaps even two years, but I >> think >> that nearly 300 years is asking a bit much. > > > 2 years is nothin

Re: Thread-ID - how much could be?

On 12Sep2014 11:29, Steven D'Aprano wrote: [...]maxint. I know that some Linux systems can have an uptime over a year, perhaps even two years, but I think that nearly 300 years is asking a bit much. 2 years is nothing. Unless they have a particularly buggy kernel, most UNIX systems, Linux in

Re: Thread-ID - how much could be?

On Fri, Sep 12, 2014 at 11:29 AM, Steven D'Aprano wrote: > I know that some Linux > systems can have an uptime over a year, perhaps even two years, but I think > that nearly 300 years is asking a bit much. Your hardware probably won't > keep working that long. I've had over two years of uptime. C

Re: Thread-ID - how much could be?

On Thu, Sep 11, 2014 at 8:29 PM, Steven D'Aprano wrote: > Suppose you somehow managed to create 9223372036854775807 threads. If your > computer has 16 GB of RAM available, that means that at most each thread > can use: > > py> 16*1024*1024*1024/9223372036854775807 > 1.862645149230957e-09 > > bytes

Re: Thread-ID - how much could be?

Ervin Hegedüs wrote: [...] >> > My question is: how much thread ID could be totally? Is there any >> > maximum number? And if the thread reached that, what will be >> > done? Overlflowed? Couting from 0 again? [...] >> There is no upper limit to the thread name other than that you will >> eventual

Re: Thread-ID - how much could be?

Ervin Hegedüs wrote: > Hi Peter, > > thanks for the reply, > > On Thu, Sep 11, 2014 at 09:48:18PM +0200, Peter Otten wrote: >> Ervin Hegedüs wrote: >> >> > Exception in thread Thread-82: >> > ... >> > My question is: how much thread ID could be totally? Is there any >> > maximum number? And if

Re: Thread-ID - how much could be?

Hi Peter, thanks for the reply, On Thu, Sep 11, 2014 at 09:48:18PM +0200, Peter Otten wrote: > Ervin Hegedüs wrote: > > > Exception in thread Thread-82: > > ... > > My question is: how much thread ID could be totally? Is there any > > maximum number? And if the thread reached that, what will be

Re: Thread-ID - how much could be?

Ervin Hegedüs wrote: > I've made a long-time running daemon, which uses threads. Looks > like that works perfectly, now I'm looking at the exceptions :). > > In the log, I found an interesting message: > > Exception in thread Thread-82: > ... > > The main function allows 2 thread to run simulta

Re: Thread terminate

On 28Aug2014 12:02, Marko Rauhamaa wrote: Ervin Hegedüs : at this time there is only one thread, as you wrote. I just try to prepare it to higher load, when one thread will not enough... Threads are a necessary evil when dealing with blocking function calls, but evil they remain. [...snip...]

Re: Thread terminate

On Thu, Aug 28, 2014 at 1:35 PM, Ervin Hegedüs wrote: > On Thu, Aug 28, 2014 at 12:34:18PM -0700, Chris Kaynor wrote: depending on what you are doing with the first two arguments to self._exit, >> the following might also work: >> >> def run(self): >> try: >> connect_to_db() >>

Re: Thread terminate

Hi Chris, On Thu, Aug 28, 2014 at 12:34:18PM -0700, Chris Kaynor wrote: > On Thu, Aug 28, 2014 at 11:39 AM, Ervin Hegedüs wrote: > > > > now the code looks like this: > > > > def run(self): > > try: > > connect_to_db() > > except: > > self._exit(-1, "Connection error", sys.e

Re: Thread terminate

On Thu, Aug 28, 2014 at 11:39 AM, Ervin Hegedüs wrote: > Hi Chris, > > thanks for you answer, > > On Thu, Aug 28, 2014 at 09:23:24AM -0700, Chris Kaynor wrote: > > On Thu, Aug 28, 2014 at 1:52 AM, Ervin Hegedüs > wrote: > > > > > > > In your case, you may want to just handle the exceptions insi

Re: Thread terminate

Hi Chris, thanks for you answer, On Thu, Aug 28, 2014 at 09:23:24AM -0700, Chris Kaynor wrote: > On Thu, Aug 28, 2014 at 1:52 AM, Ervin Hegedüs wrote: > > > > > In your case, you may want to just handle the exceptions inside the > > > thread's run() function directly. If that is not possible an

Re: Thread terminate

On Fri, Aug 29, 2014 at 2:23 AM, Chris Kaynor wrote: > If what you want is to make sure the error is not printed to stderr, you'll > just need to make sure the thread's run function does not exit with an > exception. The simpliest way to do that would be to wrap the entire thread's > run function

Re: Thread terminate

On Thu, Aug 28, 2014 at 1:52 AM, Ervin Hegedüs wrote: > > > In your case, you may want to just handle the exceptions inside the > > thread's run() function directly. If that is not possible and you really > > need to handle them inside the main thread, you would need to store off > the > > error

Re: Thread terminate

On Wed, Aug 27, 2014 at 1:55 PM, Ervin Hegedüs wrote: > what's the correct way to terminate a thread by itself? If this is something you need to do as a regular course of business, I'd share a Queue between the main thread and the target thread. When you want it to exit, shoot it a command to d

Re: Thread terminate

Hi Marko, On Thu, Aug 28, 2014 at 12:02:29PM +0300, Marko Rauhamaa wrote: > Ervin Hegedüs : > > > at this time there is only one thread, as you wrote. I just try > > to prepare it to higher load, when one thread will not enough... > > Threads are a necessary evil when dealing with blocking funct

Re: Thread terminate

Ervin Hegedüs : > at this time there is only one thread, as you wrote. I just try > to prepare it to higher load, when one thread will not enough... Threads are a necessary evil when dealing with blocking function calls, but evil they remain. I would generally *not* associate a thread for each pa

Re: Thread terminate

Hi Chris, thanks for the reply, On Wed, Aug 27, 2014 at 12:26:48PM -0700, Chris Kaynor wrote: > On Wed, Aug 27, 2014 at 11:55 AM, Ervin Hegedüs wrote: > > > what's the correct way to terminate a thread by itself? > > > > To terminate the thread, the run function must exit. This can be either >

Re: Thread terminate

On Wed, Aug 27, 2014 at 11:55 AM, Ervin Hegedüs wrote: > what's the correct way to terminate a thread by itself? > To terminate the thread, the run function must exit. This can be either from an exception or a return statement. > > I mean: > > class MyThread(threading.Thread): > def __init

Re: Thread._stop() behavior changed in Python 3.4

On Mar 17, 2014 12:53 PM, "Jurko Gospodnetić" wrote: > > Hi. > > > On 17.3.2014. 19:03, Ian Kelly wrote: >> >> So yes, despite the lack of true concurrency, a thread can continue to >> run after its _stop has been called. > > > Actually 'true' or 'false' concurrency does not matter here. > >

Re: Thread._stop() behavior changed in Python 3.4

Hi. On 17.3.2014. 19:03, Ian Kelly wrote: So yes, despite the lack of true concurrency, a thread can continue to run after its _stop has been called. Actually 'true' or 'false' concurrency does not matter here. CPython supports multiple threads and implements them using underlying nati

Re: Thread._stop() behavior changed in Python 3.4

On Tue, Mar 18, 2014 at 5:13 AM, Felix Yan wrote: > On Tuesday, March 18, 2014 05:08:20 Chris Angelico wrote: >> I've posted comments on both the issues you linked to. My guess based >> on a cursory look at paramiko is that it's a test suite watchdog, >> which would be much better implemented with

Re: Thread._stop() behavior changed in Python 3.4

On Tuesday, March 18, 2014 05:08:20 Chris Angelico wrote: > I've posted comments on both the issues you linked to. My guess based > on a cursory look at paramiko is that it's a test suite watchdog, > which would be much better implemented with a subprocess; I may be > wrong, though. In any case, if

Re: Thread._stop() behavior changed in Python 3.4

On Tue, Mar 18, 2014 at 4:59 AM, Felix Yan wrote: > For now I just skipped the test suites for paramiko to get the packaging done > (since the test suites themselves are passed without a problem, just the test > script made something wrong). I'll try to follow up the issue for paramiko :) I've po

Re: Thread._stop() behavior changed in Python 3.4

On Mon, Mar 17, 2014 at 11:40 AM, Chris Angelico wrote: > Antoine says that this doesn't even stop the thread > (I can't say; I've never used _stop(), for obvious reasons), so this > code was doubly broken. I was curious about that -- after all, Python's threads aren't truly concurrent, so perhap

Re: Thread._stop() behavior changed in Python 3.4

On Monday, March 17, 2014 17:33:09 Antoine Pitrou wrote: > Hi, > > Felix Yan gmail.com> writes: > > A minimized snippet to reproduce: > > > > #!/usr/bin/python > > import threading > > > > def stale(): > > import time > > time.sleep(1000) > > > > t = threading.Thread(target=stale) > >

Re: Thread._stop() behavior changed in Python 3.4

On Tue, Mar 18, 2014 at 4:18 AM, Felix Yan wrote: > I noticed a behavior change on Thread._stop() with Python 3.4. > > I know the method is an undocumented "feature" itself, but some projects are > using it, and now they fail. > > I know trying to forcefully stop a thread is not really a good prac

Re: Thread._stop() behavior changed in Python 3.4

Hi, Felix Yan gmail.com> writes: > > A minimized snippet to reproduce: > > #!/usr/bin/python > import threading > def stale(): > import time > time.sleep(1000) > t = threading.Thread(target=stale) > t.start() > t._stop() > > This works correctly with Python 3.3, the program exits imme

Re: Thread is somehow interfering with a while loop called after the thread is started

On 28-7-2013 4:29, dan.h.mciner...@gmail.com wrote: > I have a simple scapy + nfqueue dns spoofing script that I want to turn into > a thread within a larger program: > > http://www.bpaste.net/show/HrlfvmUBDA3rjPQdLmdp/ > > Below is my attempt to thread the program above. Somehow, the only way t

Re: Thread-safe way to prevent decorator from being nested

Michael wrote: > I'm writing a decorator that I never want to be nested. Following from the > answer on my StackOverflow question > (http://stackoverflow.com/a/16905779/106244), I've adapted it to the > following. > > Can anyone spot any issues with this? It'll be run in a multi-threaded > enviro

Re: thread example question

On 18/01/2012 4:22 PM, Rodrick Brown wrote: import _thread as thread import time class thread_counter(object): def __init__(self, thr_cnt, sleep_int): self.thr_cnt = thr_cnt self.sleep_int = sleep_int def counter(myId, count): for i in range(count): time.sle

RE: Thread problem

Can someone help me on this please? From: python-list-bounces+nikunj.badjatya=emc@python.org [mailto:python-list-bounces+nikunj.badjatya=emc@python.org] On Behalf Of nikunj.badja...@emc.com Sent: Wednesday, November 23, 2011 11:15 AM To: python-list@python.org Subject: Thread problem H

Re: Thread handling issue

TRY to get BOA with wxpython! Please check the example for the UI part in BOA. -- http://mail.python.org/mailman/listinfo/python-list

  1   2   3   4   >