I'm running the code below. From terminal I'm putting python test.py. But it's giving me nothing.
###test.py### Version 2
from threading import Timer
def hello():
print "Hello"
t=Timer(5, hello)
t.start()
I tried the same code in a different machine, it's showing me the output properly. I tried going step by step. I kept only the print statement and it's working fine. Then I added that print to a function, and called the function, it is also working fine. As soon as I add the Timer, the python command keeps on running without showing any output, until I stop it by force.
Previously the same thing happened with scapy library. But after a system restart it worked fine. But now it is not working after the system restart also.
What could be the problem?
Note 1: 6 days back, it was not behaving like this. Is there any chance of any malwares?
Note 2: A peculiar behaviour.
###test.py### Version 1
from threading import Timer
from time import sleep
def hello():
print "Hello"
t=Timer(5, hello)
t.start()
sleep(10)
This was my version 1. After it didn't work, I modified it to Version 2 which is mentioned above. Still no output. But when I press ctrl+c, It's showing
from time import sleep as _sleep
File .........., line 2, in <module>
KeyboardInterrupt
Though that line of code is not present there. I rechecked the saved file whether I saved or not. I also checked whether any pyc file is creating trouble or not. But no pyc was there.
You have a file named time.py in the same directory as test.py. (Or you did have one, and still have time.pyc. Or you have some somewhere else in your sys.path for some reason.)
When you do import time or from time import sleep, it's not opening the stdlib's time, it's opening your time.py.
And even if you don't do that, inside threading:*
from time import time as _time, sleep as _sleep
So, if your time.py doesn't have a sleep method, this will just raise an exception. But if it does, that's when things get fun. Everything will seem to work fine, until the Timer thread sleeps for 5 seconds by (ultimately) calling a block-and-spin loop inside Condition.wait. If your time.sleep function isn't actually sleeping, or if it multiplies the sleep time by 1000, or whatever, that could cause it to burn up 100% CPU busy-waiting, or to take much longer than 5 seconds to fire, or who knows what.
Likewise, scapy is almost certainly using the time module, which is why it's having the same problem.
At any rate, you can test this pretty easily:
$ python2.7
>>> import time
>>> time.__file__
/usr/lib/python2.7/lib-dynload/time.so
>>> import threading
>>> threading.__file__
/usr/lib/python2.7/threading.pyc
If the results aren't similar to that, there's your problem.
* The copy of 2.7.6 I have lying around is slightly different, but I assume Fedora 21 will be closer to the latest 2.7 trunk than 2.7.6, so that's what I linked to… At any rate, the differences don't matter.