Has anyone tried to run pg8000, a pure Python PostgreSQL DB-API 2.0
implementation, under IronPython? If so, I would be interested in how
well it worked.
Many thanks for you help.
Olaf
--
http://mail.python.org/mailman/listinfo/python-list
How do I compile omniORBpy 3.0 on Windows? The readme.txt file seems
to talk only about how to do this on Unix. Unfortenuately, I can not
use the binary because I need to use Python 2.3.5. (and the binary
requires that I use Python 2.4).
I tried to copy the omniORBpy 3.0 source code to top\src\l
Update
The problem turned out to be the BIOS of the PC we were using. The
Python test program has been running fine for 5 days now (after we
upgraded the system BIOS) and is still running fine.
Sorry, I do not have any information as to what was fixed in the BIOS.
Also, I do not know exactly who
Grant
> You might want to run some memory tests.
We have multiple identical boxes and they all have the same problem.
Olaf
--
http://mail.python.org/mailman/listinfo/python-list
This is an update on what we found so far:
We located one other PC that was not identical to the PC with the
problem. So we installed Windows XP on it and ran the Python test
program. It ran fine all night w/o locking up.
Here is what winmsd reports for this PC:
winmsd:
OS Name: Microsoft Windo
Robin and Roel
Thanks for trying and reporting the results. Both of you and Tim and
Dave have run the .py program now (all on hyper-threaded CPUs) and none
of you were able to reproduce the problem.
So that indicates that there is something special about our PC. We are
planing to re-install Win
Tim, Serge, Dennis
Yes it happens every time. The PC does not run any other programs. We
have tried multiple PC but they all have an identical configuration.
We usually start the test leave the PC alone. The best way to test my
posted .py program is to start the test before going to lunch or be
Dave send me the below as an email. Olaf
Hi Olaf,
I'm running your test for you - it's been going for about an hour now
and is continuing to generate output[1].
c:\>py
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license"
Tim
Many thanks for trying and reporting the details of your environment.
All our hyper-threading PC are identical. However, we identified one
that is different and we are installing Windows XP on it now ...
My hope is that other people will try this, too.
Olaf
--
http://mail.python.org/mailm
Below are 2 files. The first is a Python program that isolates the
problem within less than 1 hour (often just a few minutes). The second
is a C++ program that shows that the Win32 Sleep() function works as
expected (ran from Friday afternoon until Monday morning).
Note, the Python programs hang
Tim
> I did this under a debug build of Python
Perhaps this is the reason why you were not able to reproduce the
problem. Could you try again with a standard build of Python?
I am a bit surprised that nobody else has tried running the short
Python program above on a hyper-threading or dual core
Marc
> IIRC it was something like an NTP daemon that caused the clock to "jump" a
> little and (Window's) sleep was confused.
The problem is not a "jump" but a permanet lockup of the sleep
statement.
To all others, is there nobody out there that could run the test code
at the beginning of this
Christophe
> Same reason that there is a warning in the "os.access" manual
I understand the if file exists open it code.
I looked at the os.access documentation and see no "warning" or "not
reliable" wording there.
6.1.4 Files and Directories
access(path, mode)
Olaf
--
http://mail.python
Grant
> Having sleep() take orders of magnitude longer than it should
I seen a few times where sleep returns after some seconds or even after
tens of seconds (my code above check for that). But most of the time
it gets stuck forever.
Olaf
--
http://mail.python.org/mailman/listinfo/python-list
Tim
> I didn't run it for hours ;-)
Please try.
The sleep statement does not return! And this should not happen. The
code above does nothing special or unusual. The problem only occurs if
2 threads use the sleep statement and hyper-threading is enabled.
We discovered this bug perhaps a year
Tim and Grant
>>>
if q.empty():
return
>>>
Of course you explanation is understood and ideally should be included
as a note in the Python documentation. And the "not reliable" should
be removed from the documentation!
Anyway, many thanks for your explanations (I feel "safer" now).
Serge
> I got bored and tried to stop it with ctrl-c ...
Yes, you have to use the ctrl-break key to stop the first program. And
neither program every hangs on a single core CPU. It also does not
hang on a hyper-threading CPU if hyper-threading is turned off in the
BIOS.
Olaf
--
http://mail.p
Tim
> Do you want someone running this test to hit the ENTER key, or not?
The purpose of the "sys.stdin.read(1)" statement is simply to prevent
the main thread from exiting and thus ending the test. And yes, I also
get an exception when I press the enter key.
Olaf
--
http://mail.python.org/ma
Time
>>>
1 2 1 2 1 2 1 2 1 1 2 1 2 1 2 1 2 1 2 1 1 2 1 2 1
2 1 2 1 2 1 1 2 1 2 1 2 1 2 1 1 2 1 2 1 2 1 2 1 2
1 1 2 1 2 1 2 1 2 1 2 1 1 2 1 2 1 2 1 2 1
>>>
This is exactly what you should see. The problem I see is that after a
while (minutes to hours) the printing of 1s and 2s stops! If you pres
> What do you mean "stop responding"?
Both threads print their thread numbers (either 1 or 2) approximately
every 10 seconds. However, after a while (minutes to hours) both
programs (see above) hang!
Pressing ctrl-c (after the printing stops) causes the threads to "wake
up" from their sleep stat
Because of multithreading semantics, this is not reliable. This
sentence is found in the Python documentation for "7.8.1 Queue
Objects".
This scares me! Why would Queue.qsize(), Queue.empty( ), and a
Queue.full() not be reliable?
Looking at the source code of Queue.py, all 3 calls use a mutex (
Below are 2 files that isolate the problem. Note, both programs hang
(stop responding) with hyper-threading turned on (a BIOS setting), but
work as expected with hyper-threading turned off.
Note, the Windows task manager shows 2 CPUs on the Performance tab with
hyper-threading is turned on.
Both
22 matches
Mail list logo
