[ python-Bugs-1234979 ] Lock.acquire treats only 1 as True
Bugs item #1234979, was opened at 2005-07-08 17:25 Message generated for change (Comment added) made by cperkins You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234979&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Chris Perkins (cperkins) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Lock.acquire treats only 1 as True Initial Comment: Lock.acquire takes an argument indicating whether or not to block. On Windows, an argument of 1 (or True) is treated as True, and any other number is treated as False. The problem is in PyThread_acquire_lock, in thread_nt.h. Although I haven't tried it on any other platform, looking at a random sample (thread_pthread.h and thread_solaris.h), it looks to me like other platforms do it right. -- >Comment By: Chris Perkins (cperkins) Date: 2005-07-09 10:43 Message: Logged In: YES user_id=1142368 It looks like thread_wince.h suffers from the same problem. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-08 18:26 Message: Logged In: YES user_id=1188172 Okay. Committed as Python/thread_nt.h r2.23.10.1, r2.24. -- Comment By: Tim Peters (tim_one) Date: 2005-07-08 18:10 Message: Logged In: YES user_id=31435 birkenfeld, yes we should: lock.acquire(waitflag) has been documented for more than a decade as treating any non-zero value as true, so this is a clear bug in thread_nt.h -- if someone was, e.g., relying on lock.acquire(2) acting like lock.acquire(0) on Windows, tough luck for them. I'd even include this patch in a bugfix release, since the current meaning of lock.acquire(2) varies across platforms because of this bug, and that's a potentially serious problem. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-08 17:59 Message: Logged In: YES user_id=1188172 Attaching a patch fixing that. Of course, the change is slightly backwards-incompatible, so should we do that? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234979&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1234979 ] Lock.acquire treats only 1 as True
Bugs item #1234979, was opened at 2005-07-08 23:25 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234979&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Chris Perkins (cperkins) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Lock.acquire treats only 1 as True Initial Comment: Lock.acquire takes an argument indicating whether or not to block. On Windows, an argument of 1 (or True) is treated as True, and any other number is treated as False. The problem is in PyThread_acquire_lock, in thread_nt.h. Although I haven't tried it on any other platform, looking at a random sample (thread_pthread.h and thread_solaris.h), it looks to me like other platforms do it right. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-09 17:27 Message: Logged In: YES user_id=1188172 I see. Fixed as Python/thread_wince.h r2.8, r2.7.30.1. -- Comment By: Chris Perkins (cperkins) Date: 2005-07-09 16:43 Message: Logged In: YES user_id=1142368 It looks like thread_wince.h suffers from the same problem. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-09 00:26 Message: Logged In: YES user_id=1188172 Okay. Committed as Python/thread_nt.h r2.23.10.1, r2.24. -- Comment By: Tim Peters (tim_one) Date: 2005-07-09 00:10 Message: Logged In: YES user_id=31435 birkenfeld, yes we should: lock.acquire(waitflag) has been documented for more than a decade as treating any non-zero value as true, so this is a clear bug in thread_nt.h -- if someone was, e.g., relying on lock.acquire(2) acting like lock.acquire(0) on Windows, tough luck for them. I'd even include this patch in a bugfix release, since the current meaning of lock.acquire(2) varies across platforms because of this bug, and that's a potentially serious problem. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-08 23:59 Message: Logged In: YES user_id=1188172 Attaching a patch fixing that. Of course, the change is slightly backwards-incompatible, so should we do that? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234979&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1235266 ] debug info file descriptor of tarfile is inconsistent
Bugs item #1235266, was opened at 2005-07-10 01:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: debug info file descriptor of tarfile is inconsistent Initial Comment: "7.19.1 TarFile Objects" says The messages are written to sys.stdout. but they are actually written to sys.stderr :: def _dbg(self, level, msg): """Write debugging output to sys.stderr. """ if level <= self.debug: print >> sys.stderr, msg There are 2 options: (a) change document from stdout to stderr. (b) rewrite the code to use stdout. Given this is debug messages and most other modules use stdout for debug printing(gc is one of the few exceptions?), I'm +1 on (b). [*] http://docs.python.org/lib/tarfile-objects.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1235266 ] debug info file descriptor of tarfile is inconsistent
Bugs item #1235266, was opened at 2005-07-09 18:24 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: debug info file descriptor of tarfile is inconsistent Initial Comment: "7.19.1 TarFile Objects" says The messages are written to sys.stdout. but they are actually written to sys.stderr :: def _dbg(self, level, msg): """Write debugging output to sys.stderr. """ if level <= self.debug: print >> sys.stderr, msg There are 2 options: (a) change document from stdout to stderr. (b) rewrite the code to use stdout. Given this is debug messages and most other modules use stdout for debug printing(gc is one of the few exceptions?), I'm +1 on (b). [*] http://docs.python.org/lib/tarfile-objects.html -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-09 19:04 Message: Logged In: YES user_id=1188172 The documentation seems to be borrowed from zipfile, where the statement is true: debug info is written to stdout. I'm in favour of changing the docs to stderr for tarfile. What about zipfile? Should we print debug info to stderr there, too? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
