Michele Simionato <[EMAIL PROTECTED]> wrote:
...
> I know about sched (it was the first thing I looked at): the problem
> is that sched
> adopt a blocking approach and it basically requires threads, whereas I
As the "sleep for time N" callable, you can pass any callable you wish;
I suggested one based on Queue.wait with timeout, which would indeed
require some other thread to wake it, but any kind of system call which
allows timeouts, such as select or poll, would work just as well.
> wanted to
> avoid them. Diez B. Roggisch's reply is closer to my expectations:
>
> >> Most probably the OS will have specialized APIs (or some wrapper lib
> >> has) that allow for reactor registration for events of different kinds
> >> including timers.
>
> But what kind of specialized API do I have at my disposition for
> timers on Linux?
> It looks like this is the question I should have asked the first
> time ;)
What do you expect from "timers on Linux" that you could not get with a
simple "sleep for the next N milliseconds"? A timer (on Linux or
elsewhere) can jog your process N milliseconds from now, e.g. with a
SIGALRM or SIGPROF, and you can set one with the setitimer syscall
(presumably accessible via ctypes, worst case -- I've never used it from
Python, yet), but how would that help you (compared to plain sleep,
select, poll, or whatever else best fits your need)?
Alex
--
http://mail.python.org/mailman/listinfo/python-list
