D
Derek Fountain
Does Python have a timer mechanism? i.e. an "after 500 milliseconds, run
this bit of code" sort of thing?
this bit of code" sort of thing?
N
Noen
http://www.python.org/Doc/lib/module-sched.htmlDerek said:
but you should perhaps also look into twisteds event-based framework who
does it even better. www.twistedmatrix.com
G
Georgy Pruss
Noen said:
The above link doesn't work. This does:
http://www.python.org/doc/current/lib/module-sched.html
D
Dave Harrison
Does Python have a timer mechanism? i.e. an "after 500 milliseconds, run
why not just use the time.sleep() function ?
why not just use the time.sleep() function ?
A
Alan Kennedy
[Derek Fountain]
Like this?
#-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
import threading
def hello():
print "hello, world"
t = threading.Timer(30.0, hello)
t.start() # after 30 seconds, "hello, world" will be printed
#-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Timers start a new thread of execution.
More info from here
http://www.python.org/doc/current/lib/timer-objects.html
HTH,
Like this?
#-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
import threading
def hello():
print "hello, world"
t = threading.Timer(30.0, hello)
t.start() # after 30 seconds, "hello, world" will be printed
#-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Timers start a new thread of execution.
More info from here
http://www.python.org/doc/current/lib/timer-objects.html
HTH,
D
Derek Fountain
Dave said:
Because that stops the thread. I want things to continue, and then be
interrupted in order to execute a bit of code. Tcl has the 'after' command:
after 5000 { set disabled 0 }
The script carries on, and after 5 seconds whatever is being done gets
interrupted in order to run a bit of script - in this case set a variable
turning off a disablement of some sort. This makes it trivial to implement
"disable this feature for 5 seconds" kinds of logic.
I can't find anything like that in Python.
A
Anthony Briggs
Wow, that must make your scripts so much more interesting to debug
Anthony
D
Derek Fountain
Alan said:
That looks like what I'm after, yes. I haven't looked into threads since
they've represented trouble in every other language I've used. But I'll
have a look into their implementation in Python and see if they're any more
usable here...
Thanks.
B
Bob Gailer
Check out the sched and time modules.
Bob Gailer
(e-mail address removed)
303 442 2625
R
Roy Smith
Check out the threading module. In particular, the threading.Timer class.
C
Cameron Laird
.
.
.
.
.
You probably think you wrote something uncontroversial.
I take this question rather seriously, as it turns out.
Scripts that are "easy to debug" make for an apt focus.
This thread is really about asynchronous or concurrent
processing, I claim, and I further claim we really don't
have *any* satisfying model for coding those. Threading
is a quagmire (everyone agree?), and our guild has demon-
strated only marginally more reliability in working with,
say, co-routines, chords, continuations, and so on. For
my money, the event-oriented model behind the [after]
above is at least as robust as any other.
Among other frailties, I hold a grudge against the aca-
demic world that it hasn't shown more leadership in this
matter.
I'll summarize: validation of event-oriented designs
implemented with [after] and similar mechanisms, is at
worst no more difficult than validation of the corre-
sponding thread-based designs. Concurrency is hard to
get right, at least with our current understanding.
.
.
.Wow, that must make your scripts so much more interesting to debug
.
.
You probably think you wrote something uncontroversial.
I take this question rather seriously, as it turns out.
Scripts that are "easy to debug" make for an apt focus.
This thread is really about asynchronous or concurrent
processing, I claim, and I further claim we really don't
have *any* satisfying model for coding those. Threading
is a quagmire (everyone agree?), and our guild has demon-
strated only marginally more reliability in working with,
say, co-routines, chords, continuations, and so on. For
my money, the event-oriented model behind the [after]
above is at least as robust as any other.
Among other frailties, I hold a grudge against the aca-
demic world that it hasn't shown more leadership in this
matter.
I'll summarize: validation of event-oriented designs
implemented with [after] and similar mechanisms, is at
worst no more difficult than validation of the corre-
sponding thread-based designs. Concurrency is hard to
get right, at least with our current understanding.
A
Alan Kennedy
[Cameron Laird]
I really don't have time to post to the level of detail I would like,
but I had to put forward a couple of thoughts.
I think you might get some disagreement from the Twisted, Medusa and
ZServer people. And possibly see a slanging match erupt on whose
design is best....
Definitely. Sometimes.
I think threads are really a useful abstraction for programmers who
are learning to deal with developing servers for the first time. And
threads fulfill their function very well, to a point.
But they have fundamental scalability problems: The C10K problem
illustrates this well: Surely it should be possible for a modern
computer, with giga-everything (!), to serve 10,000 clients
simultaneously?
http://www.kegel.com/c10k.html
To go beyond the performance limits imposed by the resource-hogging
threads (OMG, > 1MB of core on some platforms!), it's necessary to
move to a different concurrency mechanism, such as coroutines, which
represents "tasklets" much more efficiently.
But event-based concurrency models suffer from a fundamental
limitation: it is more difficult to spread work across multiple
processors. CPython, to some degree, lets event-based developers off
the hook, because the presence of the GIL allows them to not address
the problem, because it wouldn't achieve anything anyway.....
And the patchy support for SSL in asynch frameworks is another
fundamental problem.
Another point in favour of threads: On a multi-processor box, the
thread abstraction generally "automagically" gives you free migration
to other processors. You (generally) don't have to change a line of
your code: the underlying [OS|VM] takes care of it.
FWIW, I think that Java has a very nice model for asynchronous IO,
with all "selectors" being thread-safe, so that "selectables" that are
ready for IO can be processed in another thread, i.e. potentially on
another processor, thus giving the best of both worlds.
http://java.sun.com/j2se/1.4.2/docs/api/java/nio/package-summary.html
Googling for "'high performance' asynchronous server" shows that both
Academia and Industry are certainly not short of powerpoint-ware on
the subject......
My €0,02: Generators (and, by extension, coroutines) will be python's
greatest advance in simplifying writing event-based server
architectures: resumable functions are a honking great idea.
regards,
I really don't have time to post to the level of detail I would like,
but I had to put forward a couple of thoughts.
I think you might get some disagreement from the Twisted, Medusa and
ZServer people. And possibly see a slanging match erupt on whose
design is best....
Definitely. Sometimes.
I think threads are really a useful abstraction for programmers who
are learning to deal with developing servers for the first time. And
threads fulfill their function very well, to a point.
But they have fundamental scalability problems: The C10K problem
illustrates this well: Surely it should be possible for a modern
computer, with giga-everything (!), to serve 10,000 clients
simultaneously?
http://www.kegel.com/c10k.html
To go beyond the performance limits imposed by the resource-hogging
threads (OMG, > 1MB of core on some platforms!), it's necessary to
move to a different concurrency mechanism, such as coroutines, which
represents "tasklets" much more efficiently.
But event-based concurrency models suffer from a fundamental
limitation: it is more difficult to spread work across multiple
processors. CPython, to some degree, lets event-based developers off
the hook, because the presence of the GIL allows them to not address
the problem, because it wouldn't achieve anything anyway.....
And the patchy support for SSL in asynch frameworks is another
fundamental problem.
Another point in favour of threads: On a multi-processor box, the
thread abstraction generally "automagically" gives you free migration
to other processors. You (generally) don't have to change a line of
your code: the underlying [OS|VM] takes care of it.
FWIW, I think that Java has a very nice model for asynchronous IO,
with all "selectors" being thread-safe, so that "selectables" that are
ready for IO can be processed in another thread, i.e. potentially on
another processor, thus giving the best of both worlds.
http://java.sun.com/j2se/1.4.2/docs/api/java/nio/package-summary.html
Googling for "'high performance' asynchronous server" shows that both
Academia and Industry are certainly not short of powerpoint-ware on
the subject......
My €0,02: Generators (and, by extension, coroutines) will be python's
greatest advance in simplifying writing event-based server
architectures: resumable functions are a honking great idea.
regards,
A
Alan Kennedy
[Cameron Laird]
I really don't have time to post to the level of detail I would like,
but I had to put forward a couple of thoughts.
I think you might get some disagreement from the Twisted, Medusa and
ZServer people. And possibly see a slanging match erupt on whose
design is best....
Definitely. Sometimes.
I think threads are really a useful abstraction for programmers who
are learning to deal with developing servers for the first time. And
threads fulfill their function very well, to a point.
But they have fundamental scalability problems: The C10K problem
illustrates this well: Surely it should be possible for a modern
computer, with giga-everything (!), to serve 10,000 clients
simultaneously?
http://www.kegel.com/c10k.html
To go beyond the performance limits imposed by the resource-hogging
threads (OMG, > 1MB of core on some platforms!), it's necessary to
move to a different concurrency mechanism, such as coroutines, which
represents "tasklets" much more efficiently.
But event-based concurrency models suffer from a fundamental
limitation: it is more difficult to spread work across multiple
processors. CPython, to some degree, lets event-based developers off
the hook, because the presence of the GIL allows them to not address
the problem, because it wouldn't achieve anything anyway.....
And the patchy support for SSL in asynch frameworks is another
fundamental problem.
Another point in favour of threads: On a multi-processor box, the
thread abstraction generally "automagically" gives you free migration
to other processors. You (generally) don't have to change a line of
your code: the underlying [OS|VM] takes care of it.
FWIW, I think that Java has a very nice model for asynchronous IO,
with all "selectors" being thread-safe, so that "selectables" that are
ready for IO can be processed in another thread, i.e. potentially on
another processor, thus giving the best of both worlds.
http://java.sun.com/j2se/1.4.2/docs/api/java/nio/package-summary.html
Googling for "'high performance' asynchronous server" shows that both
Academia and Industry are certainly not short of powerpoint-ware on
the subject......
My €0,02: Generators (and, by extension, coroutines) will be python's
greatest advance in simplifying writing event-based server
architectures: resumable functions are a honking great idea.
regards,
I really don't have time to post to the level of detail I would like,
but I had to put forward a couple of thoughts.
I think you might get some disagreement from the Twisted, Medusa and
ZServer people. And possibly see a slanging match erupt on whose
design is best....
Definitely. Sometimes.
I think threads are really a useful abstraction for programmers who
are learning to deal with developing servers for the first time. And
threads fulfill their function very well, to a point.
But they have fundamental scalability problems: The C10K problem
illustrates this well: Surely it should be possible for a modern
computer, with giga-everything (!), to serve 10,000 clients
simultaneously?
http://www.kegel.com/c10k.html
To go beyond the performance limits imposed by the resource-hogging
threads (OMG, > 1MB of core on some platforms!), it's necessary to
move to a different concurrency mechanism, such as coroutines, which
represents "tasklets" much more efficiently.
But event-based concurrency models suffer from a fundamental
limitation: it is more difficult to spread work across multiple
processors. CPython, to some degree, lets event-based developers off
the hook, because the presence of the GIL allows them to not address
the problem, because it wouldn't achieve anything anyway.....
And the patchy support for SSL in asynch frameworks is another
fundamental problem.
Another point in favour of threads: On a multi-processor box, the
thread abstraction generally "automagically" gives you free migration
to other processors. You (generally) don't have to change a line of
your code: the underlying [OS|VM] takes care of it.
FWIW, I think that Java has a very nice model for asynchronous IO,
with all "selectors" being thread-safe, so that "selectables" that are
ready for IO can be processed in another thread, i.e. potentially on
another processor, thus giving the best of both worlds.
http://java.sun.com/j2se/1.4.2/docs/api/java/nio/package-summary.html
Googling for "'high performance' asynchronous server" shows that both
Academia and Industry are certainly not short of powerpoint-ware on
the subject......
My €0,02: Generators (and, by extension, coroutines) will be python's
greatest advance in simplifying writing event-based server
architectures: resumable functions are a honking great idea.
regards,
A
Anand Pillai
Python standard library offers a 'Timer' class as part
of its threading library.
The documentation should be reachable at
http://www.python.org/doc/current/lib/timer-objects.html
It is easy to create your own timer objects by using
python threads.
Here is a sample code for the same. It is a working
code, and creates a custom timer class with a maximum
timeout, which calls the function again and again until
it times out. It is different from the standard timer
which calls its target function just once.
----------------<snip>-----<snip>--------------------
from threading import Thread
import time
class ModifiedTimer(Thread):
def __init__(self, interval, maxtime, target):
self.__interval = interval
self.__maxtime = maxtime
self.__tottime = 0.0
self.__target = target
self.__flag = 0
Thread.__init__(self, None, 'mytimer', None)
def run(self):
while self.__flag==0:
time.sleep(self.__interval)
self.__target()
self.__tottime += self.__interval
if self.__tottime >= self.__maxtime:
print 'Timing out...'
self.end()
def end(self):
self.__flag=1
class MyTimer:
def __init__(self):
self.__interval = 5.0
def __timerfunc(self):
print 'Hello, this is the timer function!'
def make_timer(self, interval):
self.__interval = interval
self.__timer = ModifiedTimer(self.__interval, 60.0, self.__timerfunc)
self.__timer.start()
if __name__=="__main__":
t=MyTimer()
t.make_timer(10.0)
------------------<snip>-----------<snip>---------------
HTH
-Anand Pillai
of its threading library.
The documentation should be reachable at
http://www.python.org/doc/current/lib/timer-objects.html
It is easy to create your own timer objects by using
python threads.
Here is a sample code for the same. It is a working
code, and creates a custom timer class with a maximum
timeout, which calls the function again and again until
it times out. It is different from the standard timer
which calls its target function just once.
----------------<snip>-----<snip>--------------------
from threading import Thread
import time
class ModifiedTimer(Thread):
def __init__(self, interval, maxtime, target):
self.__interval = interval
self.__maxtime = maxtime
self.__tottime = 0.0
self.__target = target
self.__flag = 0
Thread.__init__(self, None, 'mytimer', None)
def run(self):
while self.__flag==0:
time.sleep(self.__interval)
self.__target()
self.__tottime += self.__interval
if self.__tottime >= self.__maxtime:
print 'Timing out...'
self.end()
def end(self):
self.__flag=1
class MyTimer:
def __init__(self):
self.__interval = 5.0
def __timerfunc(self):
print 'Hello, this is the timer function!'
def make_timer(self, interval):
self.__interval = interval
self.__timer = ModifiedTimer(self.__interval, 60.0, self.__timerfunc)
self.__timer.start()
if __name__=="__main__":
t=MyTimer()
t.make_timer(10.0)
------------------<snip>-----------<snip>---------------
HTH
-Anand Pillai
C
Cameron Laird
This is mostly a "me, too" follow-up. I decided
to post it, though, if only to ensure
that Twisted et al. don't feel abused. I am VERY
fond of Twisted, Medusa, and Zope, and have even
written an (unpublished, still) article on their
concurrency management. I, also, won't go into
detail now; I just want to make clear that I think
they're great, and was excluding them only for
categorical reasons.
.
[much truth]
.
.
Worth repeating.
.
.
.
D
Derek Fountain
Wow, that must make your scripts so much more interesting to debug
) I suppose it depends how you use it. It's implemented using event
processing, so nothing really happens concurrently, even on SMP boxes. So
it's not as confusing as it could be with a threaded model.
) I suppose it depends how you use it. It's implemented using eventprocessing, so nothing really happens concurrently, even on SMP boxes. So
it's not as confusing as it could be with a threaded model.
D
Dave Harrison
why not just use the time.sleep() function ?
*chuckle* must've missed that start of the thread ;-) never saw
the word threading.
Deadlock-is-a-pain-to-debug-ingly yours
Dave
*chuckle* must've missed that start of the thread ;-) never saw
the word threading.
Deadlock-is-a-pain-to-debug-ingly yours
Dave
A
Anthony Briggs
Wow, that must make your scripts so much more interesting to debug
You probably think you wrote something uncontroversial.[/QUOTE]
No, I wrote something that I consider true. I'd consider that after
command to be on a par with Fortran's(?) COME FROM statement in terms
of being able to create subtle bugs.
Yes, that's what I said - only with fewer words
Anthony
A
Alex Martelli
Anthony Briggs wrote:
...
Intercal. Lawrence Clark's 1973 article about "comefrom" in Fortran
was satire (just as all of Intercal is).
Note that, in Python, you have that 'after' available any time
you're running a Tkinter GUI: any Tkinter widget has an 'after'
method that takes a delay (in milliseconds), a callable object,
and optionally some arguments, and schedules the callable to
be called with those arguments after that delay.
It works a charm, btw.
I thought you were arguing AGAINST the 'after' functionality,
and therefore against event-driven programming...?!
Surely, if I do have a program that's architected around
responding to asynchronous events (as GUIs invariably are,
as network programming can be with asyncore or Twisted),
the ability to explicitly schedule an event (thus a callback)
for some time in the future is no problem - just handy!
Alex
...
Intercal. Lawrence Clark's 1973 article about "comefrom" in Fortran
was satire (just as all of Intercal is).
Note that, in Python, you have that 'after' available any time
you're running a Tkinter GUI: any Tkinter widget has an 'after'
method that takes a delay (in milliseconds), a callable object,
and optionally some arguments, and schedules the callable to
be called with those arguments after that delay.
It works a charm, btw.
Yes, that's what I said - only with fewer words
I thought you were arguing AGAINST the 'after' functionality,
and therefore against event-driven programming...?!
Surely, if I do have a program that's architected around
responding to asynchronous events (as GUIs invariably are,
as network programming can be with asyncore or Twisted),
the ability to explicitly schedule an event (thus a callback)
for some time in the future is no problem - just handy!
Alex
A
Alex Martelli
Alan Kennedy wrote:
...
Hmmm, what's wrong with Twisted+pyOpenSSL...? Seems to work fine...
*blink*? Uh, doesn't that depend on how you choose to have your
threads communicate with each other? The most Pythonic solution
is generally to have threads communicate via Queue instances. Can
you point me to a "cross-process Queue" class for Linux and Windows?
Not a rhetoric question -- I'd LIKE to be able to scale things up that
way, but see some problems with translating typical Queue use idioms,
particularly in a cross-platform way, to cross-process:
-- N1 client-threads posting workrequests to Q and N2 worker-threads
peeling workrequests off Q and working on them;
-- a workrequest including a reference to the Queue instance on
which the worker-thread is going to post the response/result
Alex
...
Hmmm, what's wrong with Twisted+pyOpenSSL...? Seems to work fine...
*blink*? Uh, doesn't that depend on how you choose to have your
threads communicate with each other? The most Pythonic solution
is generally to have threads communicate via Queue instances. Can
you point me to a "cross-process Queue" class for Linux and Windows?
Not a rhetoric question -- I'd LIKE to be able to scale things up that
way, but see some problems with translating typical Queue use idioms,
particularly in a cross-platform way, to cross-process:
-- N1 client-threads posting workrequests to Q and N2 worker-threads
peeling workrequests off Q and working on them;
-- a workrequest including a reference to the Queue instance on
which the worker-thread is going to post the response/result
Alex