[ python-Bugs-1607041 ] Condition.wait timeout fails when system clock changes
Bugs item #1607041, was opened at 2006-12-01 10:45 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=1607041&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: BC (hashstat) Assigned to: Nobody/Anonymous (nobody) Summary: Condition.wait timeout fails when system clock changes Initial Comment: If the system clock is adjusted after Condition.wait is called with a timeout, the timeout does not expire as expected. This appears to be due to the threading.Condition class using the system clock to calculate the timeout expiration without taking system clock changes into account. Let me illustrate this with an example: import threading c = threading.Condition() c.acquire() try: ... c.wait(3600.0) ... finally: c.release() Let's say the above snippet is executed at 08:00. Assuming the condition is never notified, the timeout should expire somewhere close to 09:00. At 08:30 someone notices that the clock is an hour fast and sets it back to 07:30. The timeout still expire around 09:00 causing a wait of 2 hours instead of the requested 1 hour. Now let's say instead that the clock was moved ahead to 09:30 at 08:30. The timeout would expire immediately after only a 30 minute wait. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1607061 ] Incorrect use of 'int' and 'long' descriptions
Bugs item #1607061, was opened at 2006-12-01 14:22 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=1607061&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: John (johnjsal) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect use of 'int' and 'long' descriptions Initial Comment: On the main page for the array module, the following is in the type code chart: 'I' unsigned int long 2 'l' signed long int 4 Should 'long' and 'int' be switched in the second column? Thanks, John -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607061&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1607061 ] Incorrect use of 'int' and 'long' descriptions
Bugs item #1607061, was opened at 2006-12-01 19:22 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607061&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.5 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: John (johnjsal) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect use of 'int' and 'long' descriptions Initial Comment: On the main page for the array module, the following is in the type code chart: 'I' unsigned int long 2 'l' signed long int 4 Should 'long' and 'int' be switched in the second column? Thanks, John -- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-01 19:40 Message: Logged In: YES user_id=849994 Originator: NO No, the second column refers to the Python type used. This is "int" for signed longs, because this is the base type for a Python int, and "long" for unsigned ints, because on most 32-bit platforms int == long and therefore an unsigned int is outside the range of a Python int. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607061&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1607041 ] Condition.wait timeout fails when system clock changes
Bugs item #1607041, was opened at 2006-12-01 13:45 Message generated for change (Comment added) made by kuran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: BC (hashstat) Assigned to: Nobody/Anonymous (nobody) Summary: Condition.wait timeout fails when system clock changes Initial Comment: If the system clock is adjusted after Condition.wait is called with a timeout, the timeout does not expire as expected. This appears to be due to the threading.Condition class using the system clock to calculate the timeout expiration without taking system clock changes into account. Let me illustrate this with an example: import threading c = threading.Condition() c.acquire() try: ... c.wait(3600.0) ... finally: c.release() Let's say the above snippet is executed at 08:00. Assuming the condition is never notified, the timeout should expire somewhere close to 09:00. At 08:30 someone notices that the clock is an hour fast and sets it back to 07:30. The timeout still expire around 09:00 causing a wait of 2 hours instead of the requested 1 hour. Now let's say instead that the clock was moved ahead to 09:30 at 08:30. The timeout would expire immediately after only a 30 minute wait. -- Comment By: Jp Calderone (kuran) Date: 2006-12-01 16:06 Message: Logged In: YES user_id=366566 Originator: NO Why should it work that way? c.wait(3600) doesn't say "wait until 0900", it says "wait 60 minutes". If you want c.waitUntil(9 oclock), maybe that would be a good API addition, but it definitely should be a separate method. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1603527 ] Python socket library confused by IPV6 notation in /etc/host
Bugs item #1603527, was opened at 2006-11-27 00:43
Message generated for change (Comment added) made by kuran
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&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: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Eric S. Raymond (esr)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python socket library confused by IPV6 notation in /etc/host
Initial Comment:
Robert J.Berger <[EMAIL PROTECTED]> reported this on the gpsd-dev mailing list
of the GPSD project.
"Until I changed the line in /etc/hosts from:
::1localhost.localdomain localhost
to:
127.0.0.1 localhost.localdomain localhost
the gps.py [library distributed by the GPSD project] would fail when trying to
open the socket connection to gpsd:
File "/usr/local/bin/spGps.py", line 198, in __init__
self.connect(host, port)
File "/usr/local/bin/spGps.py", line 237, in connect
raise socket.error, msg
socket.error: (111, 'Connection refused')
This is with Python 2.4.4 under Red Hat Linux, kernel version not reported.
Robert believes, and I concur, that this is not a GPSD bug. Rather, something
lower-level -- possibly the Python socket library, possibly some C library it
uses -- is having indigestion on the IPV6 notation.
--
Comment By: Jp Calderone (kuran)
Date: 2006-12-01 16:10
Message:
Logged In: YES
user_id=366566
Originator: NO
This seems to work fine for me:
>>> s = socket.socket(socket.AF_INET6)
>>> s.bind(('ip6-localhost', 8091))
>>> s.getsockname()
('::1', 8091, 0, 0)
>>>
[EMAIL PROTECTED]:~$ grep ip6-localhost /etc/hosts
::1 ip6-localhost ip6-loopback
[EMAIL PROTECTED]:~$
Are you sure this isn't a local misconfiguration? Perhaps gpsd isn't
listening on ::1, only 127.1?
--
Comment By: Eric S. Raymond (esr)
Date: 2006-11-29 16:35
Message:
Logged In: YES
user_id=3060
Originator: YES
host is 'localhost'
port is 2947
What's going on here is that gps.py is a Python client module for a local
daemon that monitors GPS devices on the host's serial and USB ports and
presents output on port 2947. While it is possible to use gps.py to
monitor a remote host, Berger wasn't doing that. The socket module threw
an error while attempting to connect to localhost.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-11-29 16:18
Message:
Logged In: YES
user_id=21627
Originator: NO
Can you please report the values of "host" and "port" when that error is
raised?
--
Comment By: Eric S. Raymond (esr)
Date: 2006-11-27 01:03
Message:
Logged In: YES
user_id=3060
Originator: YES
Berger reports the kernel is 2.6.18. Fedora Core 6.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1598083 ] Top-level exception handler writes to stdout unsafely
Bugs item #1598083, was opened at 2006-11-16 18:50 Message generated for change (Settings changed) made by kuran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598083&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: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 6 Private: No Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Top-level exception handler writes to stdout unsafely Initial Comment: When an exception reaches the top frame and is displayed by the exception handler, they are handled by formatting them to stderr. This involves a series of calls to PyFile_WriteString, either directly from PyErr_Display or indirectly through PyTraceBack_Print. Few, if any, of these PyFile_WriteString calls have their result checked for error. Worse, PyFile_WriteString itself does not check the return value of fputs(). So, for example, with a signal handler installed, a signal received while a traceback is being printed can result in the traceback _not_ being printed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598083&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1607041 ] Condition.wait timeout fails when system clock changes
Bugs item #1607041, was opened at 2006-12-01 10:45
Message generated for change (Comment added) made by hashstat
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&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: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: BC (hashstat)
Assigned to: Nobody/Anonymous (nobody)
Summary: Condition.wait timeout fails when system clock changes
Initial Comment:
If the system clock is adjusted after Condition.wait is called with a timeout,
the timeout does not expire as expected. This appears to be due to the
threading.Condition class using the system clock to calculate the timeout
expiration without taking system clock changes into account. Let me illustrate
this with an example:
import threading
c = threading.Condition()
c.acquire()
try:
...
c.wait(3600.0)
...
finally:
c.release()
Let's say the above snippet is executed at 08:00. Assuming the condition is
never notified, the timeout should expire somewhere close to 09:00. At 08:30
someone notices that the clock is an hour fast and sets it back to 07:30. The
timeout still expire around 09:00 causing a wait of 2 hours instead of the
requested 1 hour.
Now let's say instead that the clock was moved ahead to 09:30 at 08:30. The
timeout would expire immediately after only a 30 minute wait.
--
>Comment By: BC (hashstat)
Date: 2006-12-01 13:57
Message:
Logged In: YES
user_id=939959
Originator: YES
Apparently my description wasn't as clear as I thought. I don't care
about the clock times in the example. They were only used to illustrate
the point. What I do care about is that if a use c.wait(3600) ("wait 60
minutes"), then my thread should wake up in roughly 60 minutes without
regard to changes in the system clock.
With the current Condition implementation, no matter what timeout is used,
setting the system clock ahead reduces or eliminates the wait while setting
the system clock back increases the wait. So if the clock is set back one
hour in the middle of a 1 microsecond wait (c.wait(1)), wait will return
in an hour and 1 microsecond. Is this the way it should work?
--
Comment By: Jp Calderone (kuran)
Date: 2006-12-01 13:06
Message:
Logged In: YES
user_id=366566
Originator: NO
Why should it work that way?
c.wait(3600) doesn't say "wait until 0900", it says "wait 60 minutes".
If you want c.waitUntil(9 oclock), maybe that would be a good API
addition, but it definitely should be a separate method.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1603527 ] Python socket library confused by IPV6 notation in /etc/host
Bugs item #1603527, was opened at 2006-11-27 05:43
Message generated for change (Comment added) made by esr
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&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: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Eric S. Raymond (esr)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python socket library confused by IPV6 notation in /etc/host
Initial Comment:
Robert J.Berger <[EMAIL PROTECTED]> reported this on the gpsd-dev mailing list
of the GPSD project.
"Until I changed the line in /etc/hosts from:
::1localhost.localdomain localhost
to:
127.0.0.1 localhost.localdomain localhost
the gps.py [library distributed by the GPSD project] would fail when trying to
open the socket connection to gpsd:
File "/usr/local/bin/spGps.py", line 198, in __init__
self.connect(host, port)
File "/usr/local/bin/spGps.py", line 237, in connect
raise socket.error, msg
socket.error: (111, 'Connection refused')
This is with Python 2.4.4 under Red Hat Linux, kernel version not reported.
Robert believes, and I concur, that this is not a GPSD bug. Rather, something
lower-level -- possibly the Python socket library, possibly some C library it
uses -- is having indigestion on the IPV6 notation.
--
>Comment By: Eric S. Raymond (esr)
Date: 2006-12-01 22:18
Message:
Logged In: YES
user_id=3060
Originator: YES
>Are you sure this isn't a local misconfiguration?
I'm not. I didn't see it happen. I suggest you email Mr. Berger and ask
him.
--
Comment By: Jp Calderone (kuran)
Date: 2006-12-01 21:10
Message:
Logged In: YES
user_id=366566
Originator: NO
This seems to work fine for me:
>>> s = socket.socket(socket.AF_INET6)
>>> s.bind(('ip6-localhost', 8091))
>>> s.getsockname()
('::1', 8091, 0, 0)
>>>
[EMAIL PROTECTED]:~$ grep ip6-localhost /etc/hosts
::1 ip6-localhost ip6-loopback
[EMAIL PROTECTED]:~$
Are you sure this isn't a local misconfiguration? Perhaps gpsd isn't
listening on ::1, only 127.1?
--
Comment By: Eric S. Raymond (esr)
Date: 2006-11-29 21:35
Message:
Logged In: YES
user_id=3060
Originator: YES
host is 'localhost'
port is 2947
What's going on here is that gps.py is a Python client module for a local
daemon that monitors GPS devices on the host's serial and USB ports and
presents output on port 2947. While it is possible to use gps.py to
monitor a remote host, Berger wasn't doing that. The socket module threw
an error while attempting to connect to localhost.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-11-29 21:18
Message:
Logged In: YES
user_id=21627
Originator: NO
Can you please report the values of "host" and "port" when that error is
raised?
--
Comment By: Eric S. Raymond (esr)
Date: 2006-11-27 06:03
Message:
Logged In: YES
user_id=3060
Originator: YES
Berger reports the kernel is 2.6.18. Fedora Core 6.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1607041 ] Condition.wait timeout fails when system clock changes
Bugs item #1607041, was opened at 2006-12-01 10:45
Message generated for change (Comment added) made by hashstat
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&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: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: BC (hashstat)
Assigned to: Nobody/Anonymous (nobody)
Summary: Condition.wait timeout fails when system clock changes
Initial Comment:
If the system clock is adjusted after Condition.wait is called with a timeout,
the timeout does not expire as expected. This appears to be due to the
threading.Condition class using the system clock to calculate the timeout
expiration without taking system clock changes into account. Let me illustrate
this with an example:
import threading
c = threading.Condition()
c.acquire()
try:
...
c.wait(3600.0)
...
finally:
c.release()
Let's say the above snippet is executed at 08:00. Assuming the condition is
never notified, the timeout should expire somewhere close to 09:00. At 08:30
someone notices that the clock is an hour fast and sets it back to 07:30. The
timeout still expire around 09:00 causing a wait of 2 hours instead of the
requested 1 hour.
Now let's say instead that the clock was moved ahead to 09:30 at 08:30. The
timeout would expire immediately after only a 30 minute wait.
--
>Comment By: BC (hashstat)
Date: 2006-12-01 14:35
Message:
Logged In: YES
user_id=939959
Originator: YES
I submitted patch# 1607149 to add checking for clock variations in the
wait method when called with a timeout.
--
Comment By: BC (hashstat)
Date: 2006-12-01 13:57
Message:
Logged In: YES
user_id=939959
Originator: YES
Apparently my description wasn't as clear as I thought. I don't care
about the clock times in the example. They were only used to illustrate
the point. What I do care about is that if a use c.wait(3600) ("wait 60
minutes"), then my thread should wake up in roughly 60 minutes without
regard to changes in the system clock.
With the current Condition implementation, no matter what timeout is used,
setting the system clock ahead reduces or eliminates the wait while setting
the system clock back increases the wait. So if the clock is set back one
hour in the middle of a 1 microsecond wait (c.wait(1)), wait will return
in an hour and 1 microsecond. Is this the way it should work?
--
Comment By: Jp Calderone (kuran)
Date: 2006-12-01 13:06
Message:
Logged In: YES
user_id=366566
Originator: NO
Why should it work that way?
c.wait(3600) doesn't say "wait until 0900", it says "wait 60 minutes".
If you want c.waitUntil(9 oclock), maybe that would be a good API
addition, but it definitely should be a separate method.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1597404 ] sqlite timestamp converter bug (floating point)
Bugs item #1597404, was opened at 2006-11-16 02:00
Message generated for change (Comment added) made by ghaering
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597404&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: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Salib (msalib_ita)
Assigned to: Gerhard Häring (ghaering)
Summary: sqlite timestamp converter bug (floating point)
Initial Comment:
The pysqlite code in Python 2.5 has a bug. This bug also exists in the upstream
pysqlite2 release, but their tracker is down so I cannot submit it there.
The bug is as follows: if you insert a datetime object into a sqlite database
and then try to retrieve the object, you will (in some cases) get a datetime
instance with a slightly smaller value for the microseconds field. This bug
occurs because pysqlite is doing pointless floating point conversions. I
describe two fixes and an extra test case below.
This bug is real. I have observed it in the wild. The test set for my
application can trigger this bug about once every 20 runs.
This is what happens:
* pysqlite includes an adapter and converter function so that datetime objects
can transparently be inserted and retrieved from a sqlite database column of
type timestamp.
* When inserting a datetime object, pysqlite's adapter will insert the
isoformat() value of the object.
* When retrieving, pysqlite will take the iso formatted string representation
of the datetime object and convert it into an actual datetime object. This
conversion is buggy.
* Check out line 71 of Lib/sqlite3/dbapi2.py. The code is:
microseconds = int(float("0." + timepart_full[1]) * 100)
And that is where the bug is. This code takes an integer value, converts it
into a float (implicitly dividing by 100, then multiplies that by 100
and takes the integer part. For most values, that process gives the result you
expect. For some values however, like 510241, that process gives slightly
smaller values because of floating point rounding.
There are two possible fixes:
1. The simple fix is to just do rounding properly by using this line in place
of the previous line:
microseconds = int(0.5 + (float("0." + timepart_full[1]) * 100))
This will eliminate the bug.
2. The better fix (IMHO) is to stop playing games with floating point numbers.
There is absolutely no reason to introduce floats into this computation. The
datetime object stores microseconds as an integer value and it gets written to
the database as a stringified integer value. Taking apart that string and
converting it into an integer is a lossless operation. My preferred fix is thus:
microseconds = int(timepart_full[1])
This will eliminate the bug and it has the benefit of being shorter as well.
I've attached a patch with my preferred fix as well as an extra test in the
pysqlite test suite (Lib/sqlite3/test/types.py). You can run the pysqlite test
suite by running Lib/sqlite3/test/types.py. Note that without my fix, the test
that I added (DateTimeTests.CheckDateTimeSubSecondsFloatingPoint) will fail but
with my fix it will pass.
--
>Comment By: Gerhard Häring (ghaering)
Date: 2006-12-01 23:48
Message:
Logged In: YES
user_id=163326
Originator: NO
Fixed in upstream pysqlite. Leaving open until next merge to Python's
sqlite3 module.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-11-16 07:18
Message:
Logged In: YES
user_id=21627
Originator: NO
Gerhard, can you please take a look? If not, unassign.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597404&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1607041 ] Condition.wait timeout fails when system clock changes
Bugs item #1607041, was opened at 2006-12-01 13:45
Message generated for change (Comment added) made by kuran
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&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: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: BC (hashstat)
Assigned to: Nobody/Anonymous (nobody)
Summary: Condition.wait timeout fails when system clock changes
Initial Comment:
If the system clock is adjusted after Condition.wait is called with a timeout,
the timeout does not expire as expected. This appears to be due to the
threading.Condition class using the system clock to calculate the timeout
expiration without taking system clock changes into account. Let me illustrate
this with an example:
import threading
c = threading.Condition()
c.acquire()
try:
...
c.wait(3600.0)
...
finally:
c.release()
Let's say the above snippet is executed at 08:00. Assuming the condition is
never notified, the timeout should expire somewhere close to 09:00. At 08:30
someone notices that the clock is an hour fast and sets it back to 07:30. The
timeout still expire around 09:00 causing a wait of 2 hours instead of the
requested 1 hour.
Now let's say instead that the clock was moved ahead to 09:30 at 08:30. The
timeout would expire immediately after only a 30 minute wait.
--
Comment By: Jp Calderone (kuran)
Date: 2006-12-01 17:50
Message:
Logged In: YES
user_id=366566
Originator: NO
Yes, I misunderstood. Please disregard my comments. :)
--
Comment By: BC (hashstat)
Date: 2006-12-01 17:35
Message:
Logged In: YES
user_id=939959
Originator: YES
I submitted patch# 1607149 to add checking for clock variations in the
wait method when called with a timeout.
--
Comment By: BC (hashstat)
Date: 2006-12-01 16:57
Message:
Logged In: YES
user_id=939959
Originator: YES
Apparently my description wasn't as clear as I thought. I don't care
about the clock times in the example. They were only used to illustrate
the point. What I do care about is that if a use c.wait(3600) ("wait 60
minutes"), then my thread should wake up in roughly 60 minutes without
regard to changes in the system clock.
With the current Condition implementation, no matter what timeout is used,
setting the system clock ahead reduces or eliminates the wait while setting
the system clock back increases the wait. So if the clock is set back one
hour in the middle of a 1 microsecond wait (c.wait(1)), wait will return
in an hour and 1 microsecond. Is this the way it should work?
--
Comment By: Jp Calderone (kuran)
Date: 2006-12-01 16:06
Message:
Logged In: YES
user_id=366566
Originator: NO
Why should it work that way?
c.wait(3600) doesn't say "wait until 0900", it says "wait 60 minutes".
If you want c.waitUntil(9 oclock), maybe that would be a good API
addition, but it definitely should be a separate method.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1605110 ] logging %(module)s reporting wrong modules
Bugs item #1605110, was opened at 2006-11-29 10:29
Message generated for change (Comment added) made by mad-marty
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1605110&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: Python Library
Group: None
>Status: Open
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Pieter Zieschang (mad-marty)
Assigned to: Vinay Sajip (vsajip)
Summary: logging %(module)s reporting wrong modules
Initial Comment:
I recently upgraded from python 2.4.2 to 2.4.4
and the logging seems to be working wrong now.
I have a formatter which uses the %(module)s and %(filename)s and the point to
the wrong file/module.
I have some plugins in .py files, which mainly have one class derived from
threading.Thread.
Those classes logging calls will now log as
2006-11-29 10:17:50 - threading.py - threading - INFO - ...
instead of
2006-11-29 10:17:50 - myplugin.py - myplugin - INFO - ...
--
>Comment By: Pieter Zieschang (mad-marty)
Date: 2006-12-02 02:09
Message:
Logged In: YES
user_id=1269426
Originator: YES
Hi,
after some investigation, I think I found the source.
Just add 'import psyco; psyco.full()' to test.py aufer imports and you get
the same problem with your example.
It seems, logging is not compatible with the way psyco creates proxy
functions.
Could be that sys._getframe returns something different. - just a guess
But it works with the old logging.
Is there any other information you may want ?
--
Comment By: Vinay Sajip (vsajip)
Date: 2006-11-30 10:18
Message:
Logged In: YES
user_id=308438
Originator: NO
I need more information. For example (N.B. lines may wrap, please adjust
if copy/pasting the code below):
#-- test.py
import module
import logging
logging.basicConfig(level=logging.DEBUG,
format="%(relativeCreated)-6d %(module)s %(filename)s
%(lineno)d - %(message)s")
logging.getLogger("test").debug("Test starting, about to start
thread...")
threads = module.start()
for t in threads:
t.join()
logging.getLogger("test").debug("All done.")
#-- test.py ends
#-- module.py
import logging
import threading
import random
import time
class MyThread(threading.Thread):
def run(self):
loops = 5
while True:
logging.getLogger("module").debug("Running in thread: %s",
threading.currentThread().getName())
time.sleep(random.random())
loops -= 1
if loops < 0:
break
class MyOtherThread(threading.Thread):
def run(self):
loops = 5
while True:
logging.getLogger("module").debug("Running in thread: %s",
threading.currentThread().getName())
time.sleep(random.random())
loops -= 1
if loops < 0:
break
def start():
t1 = MyThread(name="Thread One")
t2 = MyOtherThread(name="Thread Two")
t1.start()
t2.start()
return t1, t2
#-- module.py ends
When I run test, I get the following output:
15 test test.py 7 - Test starting, about to start thread...
15 module module.py 11 - Running in thread: Thread One
15 module module.py 22 - Running in thread: Thread Two
327module module.py 11 - Running in thread: Thread One
343module module.py 22 - Running in thread: Thread Two
655module module.py 11 - Running in thread: Thread One
780module module.py 22 - Running in thread: Thread Two
1000 module module.py 11 - Running in thread: Thread One
1546 module module.py 22 - Running in thread: Thread Two
1890 module module.py 11 - Running in thread: Thread One
2046 module module.py 11 - Running in thread: Thread One
2218 module module.py 22 - Running in thread: Thread Two
2562 module module.py 22 - Running in thread: Thread Two
3187 test test.py 11 - All done.
This is the expected output. Python version used:
ActivePython 2.4.3 Build 12 (ActiveState Software Inc.) based on
Python 2.4.3 (#69, Apr 11 2006, 15:32:42) [MSC v.1310 32 bit (Intel)] on
win32
--
Comment By: Pieter Zieschang (mad-marty)
Date: 2006-11-29 13:02
Message:
Logged In: YES
user_id=1269426
Originator: YES
Checked again and found that the bug was introduced with Python 2.4.2.
Last correctly working version is python-2.4.1.msi.
--
Comment By: Pieter Zieschang (mad-marty)
Date: 2006-11-29 10:32
Message:
Logged In: YES
user_id=1269426
Originator: YES
Forgot to add, that is is the 2.4.4 windows package used on windows xp.
;-)
--
