Timer

[Derek Fountain]

Does Python have a timer mechanism? i.e. an "after 500 milliseconds, run
this bit of code" sort of thing?

[Noen]

Derek Fountain wrote:

Does Python have a timer mechanism? i.e. an "after 500 milliseconds, run
this bit of code" sort of thing?

http://www.python.org/Doc/lib/module-sched.html

but you should perhaps also look into twisteds event-based framework who
does it even better. www.twistedmatrix.com

[Georgy Pruss]

"Noen" <no***********@na.no> wrote in message news:zp*********************@juliett.dax.net...

Derek Fountain wrote:

Does Python have a timer mechanism? i.e. an "after 500 milliseconds, run
this bit of code" sort of thing?

http://www.python.org/Doc/lib/module-sched.html

The above link doesn't work. This does:

http://www.python.org/doc/current/lib/module-sched.html
--
Georgy Pruss
E^mail: 'ZDAwMTEyMHQwMzMwQGhvdG1haWwuY29t\n'.decode('base6 4')

[Dave Harrison]

> > > Does Python have a timer mechanism? i.e. an "after 500 milliseconds, run

this bit of code" sort of thing?

why not just use the time.sleep() function ?

[Alan Kennedy]

[Derek Fountain]

Does Python have a timer mechanism? i.e. an "after 500 milliseconds, run
this bit of code" sort of thing?

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/li...r-objects.html

HTH,

--
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan: http://xhaus.com/mailto/alan

[Derek Fountain]

Dave Harrison wrote:

> > Does Python have a timer mechanism? i.e. an "after 500 milliseconds,
> > run this bit of code" sort of thing?

why not just use the time.sleep() function ?

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.

[Derek Fountain]

Alan Kennedy wrote:

[Derek Fountain]

Does Python have a timer mechanism? i.e. an "after 500 milliseconds, run
this bit of code" sort of thing?

Like this?
http://www.python.org/doc/current/li...r-objects.html

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.

[Anthony Briggs]

At 9:04 PM +0800 27/10/03, Derek Fountain wrote:

Dave Harrison wrote:

> > Does Python have a timer mechanism? i.e. an "after 500 milliseconds,
> > run this bit of code" sort of thing?

why not just use the time.sleep() function ?

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.

Wow, that must make your scripts so much more interesting to debug ;)

Anthony
--
----------------------------------------------------
HyPEraCtiVE? HeY, WhO aRE YoU cALliNg HypERaCtIve?!
aB*****@wEStNeT.cOm.aU
----------------------------------------------------

[Bob Gailer]

At 09:21 PM 10/26/2003, Derek Fountain wrote:

Does Python have a timer mechanism? i.e. an "after 500 milliseconds, run
this bit of code" sort of thing?

Check out the sched and time modules.

Bob Gailer
bg*****@alum.rpi.edu
303 442 2625
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.525 / Virus Database: 322 - Release Date: 10/9/2003

[Roy Smith]

In article <3f***********************@freenews.iinet.net.au >,
Derek Fountain <no****@hursley.ibm.com> wrote:

Dave Harrison wrote:

> > Does Python have a timer mechanism? i.e. an "after 500 milliseconds,
> > run this bit of code" sort of thing?

why not just use the time.sleep() function ?

Because that stops the thread.

Check out the threading module. In particular, the threading.Timer class.

[Cameron Laird]

In article <ma************************************@python.org >,
Anthony Briggs <ab*****@westnet.com.au> wrote:

[Alan Kennedy]

[Cameron Laird]

This thread is really about asynchronous or concurrent
processing,
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 claim, and I further claim we really don't
have *any* satisfying model for coding those.
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....
Threading
is a quagmire (everyone agree?),
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.
and our guild has demonstrated 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.
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/...e-summary.html
Among other frailties, I hold a grudge against the aca-
demic world that it hasn't shown more leadership in this
matter.
Googling for "'high performance' asynchronous server" shows that both
Academia and Industry are certainly not short of powerpoint-ware on
the subject......
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.

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,

--
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan: http://xhaus.com/mailto/alan

[Alan Kennedy]

[Cameron Laird]

This thread is really about asynchronous or concurrent
processing,
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 claim, and I further claim we really don't
have *any* satisfying model for coding those.
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....
Threading
is a quagmire (everyone agree?),
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.
and our guild has demonstrated 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.
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/...e-summary.html
Among other frailties, I hold a grudge against the aca-
demic world that it hasn't shown more leadership in this
matter.
Googling for "'high performance' asynchronous server" shows that both
Academia and Industry are certainly not short of powerpoint-ware on
the subject......
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.

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,

--
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan: http://xhaus.com/mailto/alan

[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/li...r-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
Bob Gailer <bg*****@alum.rpi.edu> wrote in message news:<ma************************************@pytho n.org>...

At 09:21 PM 10/26/2003, Derek Fountain wrote:

Does Python have a timer mechanism? i.e. an "after 500 milliseconds, run
this bit of code" sort of thing?

Check out the sched and time modules.

Bob Gailer
bg*****@alum.rpi.edu
303 442 2625

--

[Cameron Laird]

In article <3F***************@hotmail.com>,
Alan Kennedy <al****@hotmail.com> wrote:

[Cameron Laird]

This thread is really about asynchronous or concurrent
processing,
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.

This is mostly a "me, too" follow-up. I decided
to post it, though, if only to ensure

I claim, and I further claim we really don't
have *any* satisfying model for coding those.

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....

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.

[Derek Fountain]

> Wow, that must make your scripts so much more interesting to debug ;)

:o) 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.

[Dave Harrison]

> > why not just use the time.sleep() function ?

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:

*chuckle* must've missed that start of the thread ;-) never saw
the word threading.

Deadlock-is-a-pain-to-debug-ingly yours
Dave

[Anthony Briggs]

At 11:59 AM -0500 27/10/03, Cameron Laird wrote:

In article <ma************************************@python.org >,
Anthony Briggs <ab*****@westnet.com.au> wrote:

>>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.
>Wow, that must make your scripts so much more interesting to debug ;)

You probably think you wrote something uncontroversial.

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.
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.

Yes, that's what I said - only with fewer words :)

Anthony
--
----------------------------------------------------
HyPEraCtiVE? HeY, WhO aRE YoU cALliNg HypERaCtIve?!
aB*****@wEStNeT.cOm.aU
----------------------------------------------------

[Alex Martelli]

Anthony Briggs wrote:
...

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
Intercal. Lawrence Clark's 1973 article about "comefrom" in Fortran
was satire (just as all of Intercal is).
of being able to create subtle bugs.

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.

my money, the event-oriented model behind the [after]
above is at least as robust as any other.

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

[Alex Martelli]

Alan Kennedy wrote:
...

And the patchy support for SSL in asynch frameworks is another
fundamental problem.
Hmmm, what's wrong with Twisted+pyOpenSSL...? Seems to work fine...
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.

*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

[Anthony Briggs]

At 11:14 AM +0000 28/10/03, Alex Martelli wrote:

Anthony Briggs wrote:
...

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
Intercal. Lawrence Clark's 1973 article about "comefrom" in Fortran
was satire (just as all of Intercal is).

Ah. I just read the article at
<http://www.fortran.com/fortran/come_from.html>. Most enlightening ;)
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'll take your word for it. It sounds like a recipe for a lot of hair
pulling to me. What happens if there's some part of your code that
you don't want interrupted? eg. database commits, file access, any
sort of time critical stuff, that sort of thing. Is there a way to
switch it off?

>>my money, the event-oriented model behind the [after]
above is at least as robust as any other.

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...?!

Perhaps I was taking his words a little too literally. As far as I
can tell with threads, etc, they're little better than voodoo. So the
after statement is at least as robust, even if it's a complete
horror...

Anthony
--
----------------------------------------------------
HyPEraCtiVE? HeY, WhO aRE YoU cALliNg HypERaCtIve?!
aB*****@wEStNeT.cOm.aU
----------------------------------------------------

[Cameron Laird]

In article <yc********************@news1.tin.it>,
Alex Martelli <al***@aleax.it> wrote:

[Alan Kennedy]

[Alan Kennedy]

And the patchy support for SSL in asynch frameworks is another
fundamental problem.
[Alex Martelli]

Hmmm, what's wrong with Twisted+pyOpenSSL...? Seems to work fine...
I haven't used that particular combination.

I was going to followup my own post to mention that my statement was
not in any way meant to be slight to any of the providers of python
SSL. For example, Ng Pheng Siong has put a lot of work into getting
M2Crypto SSL working in non-blocking mode.

My understanding is that using SSL in non-blocking mode is problematic
because SSL-level packets can trigger readiness notification on an SSL
socket when in fact there is no application-level data available.

Here is a link that discusses the problem

http://www.openssl.org/support/faq.html#PROG9

I honestly don't know if all of the asynch models implemented in
python address this problem, and would be happy to be enlightened
and/or proven completely wrong if they have.

Java nio has this problem, which will be addressed in java 1.5

http://www.itworld.com/nl/java_sec/09142001/

[Alan Kennedy] 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.

[Alex Martelli] *blink*? Uh, doesn't that depend on how you choose to have your
threads communicate with each other?
There is assumption behind my statement: that the underlying [OS|VM]
also maps the memory space of threads running on different processors
so that they coincide, and all objects are shared between threads as
if they were local to the "process" containing the threads.

If I use a Queue.Queue in jython, (AFAICT) the different threads can
be running on different processors, and the Queue.Queue will work just
fine as a synch mechanism.
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?
I'd love to. However, python's Queue.Queue class doesn't work across
processes, only across threads. But those threads could still
potentially be running on multiple processors in the same box (see
above re jython).

It'd be nice if we could have a Queue.Queue style IPC mechanism that
worked between processes, and that could be included in the set of
"selectables" for an event-driven framework. Without copious
serialization/pickling. I have stated that several times in this
forum.
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

I was interested to read about TupleSpaces from a recent post. Though
I haven't looked into TupleSpaces in detail, I can imagine that
there's lots of de/serialization going on.

Lastly, another area which seems to have patchy support across
operating systems is that of non-blocking file-locks, which would be
required for many event-driven apps.

regards,

--
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan: http://xhaus.com/mailto/alan

[Cameron Laird]

In article <ma************************************@python.org >,
Anthony Briggs <ab*****@westnet.com.au> wrote:

[Alex Martelli]

Anthony Briggs wrote:
...

I'll take your word for it. It sounds like a recipe for a lot of hair
pulling to me. What happens if there's some part of your code that
you don't want interrupted? eg. database commits, file access, any
sort of time critical stuff, that sort of thing. Is there a way to
switch it off?
Event-driven processing, AKA asynchronous processing, is not
pre-emptive: on the contrary, it relies on each event handler
(callback) terminating reasonably promptly and thus returning
to the main loop. Hmmm -- ever programmed a GUI...?

I thought you were arguing AGAINST the 'after' functionality,
and therefore against event-driven programming...?!

Perhaps I was taking his words a little too literally. As far as I
can tell with threads, etc, they're little better than voodoo. So the

Threads are best kept in their place by keeping them well separated
with Queue instances, although I wouldn't be surprised to hear that
the blood of a black roster strangled at midnight is also effective.
after statement is at least as robust, even if it's a complete
horror...

Nope -- the callback is done in the same thread that requested
it, so "thread separation" is not at issue.
Alex

[Alex Martelli]

Cameron Laird wrote:

In article <yc********************@news1.tin.it>,
Alex Martelli <al***@aleax.it> wrote:
.
.
.

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 want to refine Alex' description: it's possible to
use after with only the slenderest connection to a
Tkinter GUI. You can "import Tkinter", and exploit
after(), without ever having to make Tkinter widgets
or windows visible on the screen.

and I'll further refine yours: "as long as you run
Tkinter's mainloop". Yes, you can hide Tkinter's root
window and still run its mainloop (I think you have
to be explicit about it though:-), as long as you don't
need any of the normal processing flow used by most
non-GUI applications (including other event-driven apps
that don't use Tkinter's mainloop -- e.g., network ones
that use asyncore or select). And the .after callback
will be able to get into play only if other callbacks
(presumably also from .after, if you have no GUI) return
reasonably promptly.

In short, I doubt using Tkinter just for the sake of
getting .after makes much sense -- you're probably at
least as well off with the much lighter-weight scheduler
module, in that case. (OTOH, if it IS possible to
give fileobjects to Tkinter to cause callbacks when
they're ready, as it is in Tcl/Tk, then using Tkinter
w/o GUI may indeed be easier than merging e.g scheduler
and select -- it depends... but last time I checked I
saw no way to get the "callback on file activity" from
Tkinter as I could back when I used Tcl/Tk...).
Alex

[Michael Hudson]

Alex Martelli <al***@aleax.it> writes:

In short, I doubt using Tkinter just for the sake of
getting .after makes much sense -- you're probably at
least as well off with the much lighter-weight scheduler
module, in that case. (OTOH, if it IS possible to
give fileobjects to Tkinter to cause callbacks when
they're ready, as it is in Tcl/Tk, then using Tkinter
w/o GUI may indeed be easier than merging e.g scheduler
and select -- it depends... but last time I checked I
saw no way to get the "callback on file activity" from
Tkinter as I could back when I used Tcl/Tk...).

Huh? _tkinter.createfilehandler() is there (pyrepl uses it). I think
only on Unix, but I think that also applies to Tcl_CreateFileHandler,
so that's not much of a surprise.

Cheers,
mwh

--
First time I've gotten a programming job that required a drug
test. I was worried they were going to say "you don't have
enough LSD in your system to do Unix programming". -- Paul Tomblin
-- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html

[Itamar Shtull-Trauring]

Alan Kennedy <al****@hotmail.com> wrote in message news:<3F***************@hotmail.com>...

My understanding is that using SSL in non-blocking mode is problematic
because SSL-level packets can trigger readiness notification on an SSL
socket when in fact there is no application-level data available.

Here is a link that discusses the problem

http://www.openssl.org/support/faq.html#PROG9

Twisted does the right thing and makes sure the user doesn't have to
worry about this. Using SSL is just as easy as using TCP in Twisted.

There are other issues with event loops, like the fact the RSA
handshake is very expensive so you want to run it in another thread.
If Twisted ever has performance issues due to this I'll probably
change the code to do just that, move the handshake stage to a
threadpool.

[Alan Kennedy]

[Alan Kennedy]

My understanding is that using SSL in non-blocking mode is problematic
because SSL-level packets can trigger readiness notification on an SSL
socket when in fact there is no application-level data available.

[Itamar Shtull-Trauring] Twisted does the right thing and makes sure the user doesn't have to
worry about this. Using SSL is just as easy as using TCP in Twisted.

There are other issues with event loops, like the fact the RSA
handshake is very expensive so you want to run it in another thread.
If Twisted ever has performance issues due to this I'll probably
change the code to do just that, move the handshake stage to a
threadpool.

Thanks for that Itamar.

IMHO, another good solution to the SSL/Non-Blocking IO problem might
be to run stunnel (www.stunnel.org) to do the SSL decode, and then
forward the decrypted requests to an non-SSL asynch server. Although I
have never tried this.

Stunnel can use OpenSSL, which means that support for hardware crypto
accelerators comes for free, etc, etc.

regards,

--
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan: http://xhaus.com/mailto/alan

[Alex Martelli]

Michael Hudson wrote:
...

and select -- it depends... but last time I checked I
saw no way to get the "callback on file activity" from
Tkinter as I could back when I used Tcl/Tk...).

Huh? _tkinter.createfilehandler() is there (pyrepl uses it). I think
only on Unix, but I think that also applies to Tcl_CreateFileHandler,
so that's not much of a surprise.

I could have sworn I got "callbacks on file activity" cross-platform
when I used Tcl/Tk, but maybe it's just a memory grown rosy with age.
Alex

[Alexandre Fayolle]

Derek Fountain a écrit :

Does Python have a timer mechanism? i.e. an "after 500 milliseconds, run
this bit of code" sort of thing?

The sched module in the standard library may be what you're looking for.

--
Alexandre Fayolle
LOGILAB, Paris (France).
http://www.logilab.com http://www.logilab.fr http://www.logilab.org
Développement logiciel avancé - Intelligence Artificielle - Formations

[Michael Hudson]

Alex Martelli <al***@aleax.it> writes:

Michael Hudson wrote:
...

and select -- it depends... but last time I checked I
saw no way to get the "callback on file activity" from
Tkinter as I could back when I used Tcl/Tk...).

Huh? _tkinter.createfilehandler() is there (pyrepl uses it). I think
only on Unix, but I think that also applies to Tcl_CreateFileHandler,
so that's not much of a surprise.

I could have sworn I got "callbacks on file activity" cross-platform
when I used Tcl/Tk, but maybe it's just a memory grown rosy with age.

Well, maybe. I haven't been near a Windows system in months & months
and have never used Tcl/Tk in isolation, so please don't be surprised
when I'm wrong about Tcl on windows :-)

Cheers,
mwh

--
Make this IDLE version 0.8. (We have to skip 0.7 because that
was a CNRI release in a corner of the basement of a government
building on a planet circling Aldebaran.)
-- Guido Van Rossum, in a checkin comment