|
Home > Archive > Unix Programming > February 2006 > Is there a timer in unix ?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Is there a timer in unix ?
|
|
| Steven Woody 2006-02-15, 3:03 am |
| searched the web, i found signal is wildely used to implement a timer.
but i think that is so complex than my need it to be. because,
1, a signal might cancel a slow system call that is *not* what i
wanted.
2, in a process, one can only set one alarm single handler, but i want
to set mutiple timers simplely.
what i need is, create a timer and tell it what to do ( a handler )
after how many seconds, then the caller continue to next line of code,
the system take care everything else.
is there such a timer in Unix? thanks.
-
woody
| |
| Pascal Bourguignon 2006-02-15, 3:03 am |
| "Steven Woody" <narkewoody@gmail.com> writes:
> searched the web, i found signal is wildely used to implement a timer.
> but i think that is so complex than my need it to be. because,
>
> 1, a signal might cancel a slow system call that is *not* what i
> wanted.
> 2, in a process, one can only set one alarm single handler, but i want
> to set mutiple timers simplely.
>
> what i need is, create a timer and tell it what to do ( a handler )
> after how many seconds, then the caller continue to next line of code,
> the system take care everything else.
>
> is there such a timer in Unix? thanks.
No. UNIX means SIMPLE.
Well, actually that depends on what you mean by "Unix". If you mean
the kernel:
A signal can cancel a slow system call, because it's simplier to write
the kernel this way. But this is no problem, because you can use a
library function around the syscalls to test when the syscall returns
with EINTR and recall it. Use fread/fwrite, or fgets/fprint instead
of read/write!
Since it's trivial to write a multi-timer library when you have a
single time library (and anyways, you always wait only for the next
event, not for the next to next event!), there's only one timer.
(Well, actually there are three times: real-time, run-time, and
profile).
But if you mean the whole OS, of course, there are libraries
implementing multiple timers.
--
__Pascal Bourguignon__ http://www.informatimago.com/
HEALTH WARNING: Care should be taken when lifting this product,
since its mass, and thus its weight, is dependent on its velocity
relative to the user.
| |
| Steven Woody 2006-02-15, 3:03 am |
|
Pascal Bourguignon wrote:
> "Steven Woody" <narkewoody@gmail.com> writes:
>
>
> No. UNIX means SIMPLE.
>
> Well, actually that depends on what you mean by "Unix". If you mean
> the kernel:
yes, i mean kernel.
>
> A signal can cancel a slow system call, because it's simplier to write
> the kernel this way. But this is no problem, because you can use a
> library function around the syscalls to test when the syscall returns
> with EINTR and recall it. Use fread/fwrite, or fgets/fprint instead
> of read/write!
>
> Since it's trivial to write a multi-timer library when you have a
> single time library (and anyways, you always wait only for the next
> event, not for the next to next event!), there's only one timer.
> (Well, actually there are three times: real-time, run-time, and
> profile).
>
ok, i got it. i think i have to organize all interesting events in a
chain and use one timer ( an alerm handler ) to fire them from the
first one at each time.
>
> But if you mean the whole OS, of course, there are libraries
> implementing multiple timers.
>
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> HEALTH WARNING: Care should be taken when lifting this product,
> since its mass, and thus its weight, is dependent on its velocity
> relative to the user.
| |
| Nils O. Selåsdal 2006-02-15, 3:03 am |
| [vbcol=seagreen]
>
> ok, i got it. i think i have to organize all interesting events in a
> chain and use one timer ( an alerm handler ) to fire them from the
> first one at each time.
>
Be careful with this approach. There is a limited amount of things
you can do in a signal handler.
People tend to integrate such timers in a main loop if they have any,
(say a main loop driven by select/poll). Some even run asyncronous
tings-to-do in a seperate thread.
| |
| Steven Woody 2006-02-15, 7:57 am |
|
Nils O. Sel=E5sdal wrote:
> Be careful with this approach. There is a limited amount of things
> you can do in a signal handler.
what you mean by 'limited amount of things' ?
>
> People tend to integrate such timers in a main loop if they have any,
> (say a main loop driven by select/poll). Some even run asyncronous
> tings-to-do in a seperate thread.
not well understand :-(
| |
| Ralf Fassel 2006-02-15, 7:57 am |
| * "Nils O. Selåsdal" <NOS@Utel.no>
| People tend to integrate such timers in a main loop if they have
| any, (say a main loop driven by select/poll). Some even run
| asyncronous tings-to-do in a seperate thread.
There is an elaborated example on timers via threads in "Programming
with Posix Threads" by D. Butenhof if you need to do it low-level.
In other higher-level languages it might be as simple as
after 1000 call_some_func
in eg. TCL.
R'
| |
| Nils O. Selåsdal 2006-02-15, 7:57 am |
| Steven Woody wrote:
> Nils O. Selåsdal wrote:
>
> what you mean by 'limited amount of things' ?
I mean there are things you simply cannot do.
e.g. call printf, malloc, fopen , and many many
other "things", directly or indirectly.
Or access a global datastructure, etc. It isn't safe,
as the signal handler might be called any time, and the program
state is in limbo - thus there is only a limited subset of things
a signal handler can perform in a safe manner.
| |
| Maxim Yegorushkin 2006-02-15, 7:57 am |
|
Steven Woody wrote:
[]
> ok, i got it. i think i have to organize all interesting events in a
> chain and use one timer ( an alerm handler ) to fire them from the
> first one at each time.
You also can use timer_create API to make it call your callback in a
different thread, so that your slow system calls do not return EINTR in
the other thread.
| |
| Fred Kleinschmidt 2006-02-17, 10:40 pm |
|
"Steven Woody" <narkewoody@gmail.com> wrote in message
news:1139981691.795888.208610@g14g2000cwa.googlegroups.com...
> searched the web, i found signal is wildely used to implement a timer.
> but i think that is so complex than my need it to be. because,
>
> 1, a signal might cancel a slow system call that is *not* what i
> wanted.
> 2, in a process, one can only set one alarm single handler, but i want
> to set mutiple timers simplely.
>
> what i need is, create a timer and tell it what to do ( a handler )
> after how many seconds, then the caller continue to next line of code,
> the system take care everything else.
>
> is there such a timer in Unix? thanks.
>
> -
> woody
>
You can use functions in the X/Xt libraries to add any number of timers
(XtAppAddTimeOut).
--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Technical Architect, Software Reuse Project
| |
| Frank Cusack 2006-02-17, 10:40 pm |
| On 14 Feb 2006 21:34:51 -0800 "Steven Woody" <narkewoody@gmail.com> wrote:
> is there such a timer in Unix? thanks.
timer_create()
-frank
| |
| Frank Cusack 2006-02-17, 10:40 pm |
| On 14 Feb 2006 21:34:51 -0800 "Steven Woody" <narkewoody@gmail.com> wrote:
> searched the web, i found signal is wildely used to implement a timer.
> but i think that is so complex than my need it to be. because,
>
> 1, a signal might cancel a slow system call that is *not* what i
> wanted.
You can configure signals to not do this, see sigaction(2).
> 2, in a process, one can only set one alarm single handler, but i want
> to set mutiple timers simplely.
>
> what i need is, create a timer and tell it what to do ( a handler )
> after how many seconds, then the caller continue to next line of code,
> the system take care everything else.
>
> is there such a timer in Unix? thanks.
See setitimer(2) and timer_create(3).
Note that the handler for these is a signal handler, so you are very
limited in what you can do in the handler. You might be better off
with some kind of event loop.
-frank
| |
| Steven Woody 2006-02-17, 10:40 pm |
|
Frank Cusack wrote:
> On 14 Feb 2006 21:34:51 -0800 "Steven Woody" <narkewoody@gmail.com> wrote:
>
> You can configure signals to not do this, see sigaction(2).
>
>
> See setitimer(2) and timer_create(3).
it's strange that my linux gets no timer_create(). i run man 3
timer_create or man 2 timer_create(), but both got errors.
| |
| Geoff Clare 2006-02-17, 10:40 pm |
| "Steven Woody" <narkewoody@gmail.com> wrote, on Fri, 17 Feb 2006:
>
> it's strange that my linux gets no timer_create(). i run man 3
> timer_create or man 2 timer_create(), but both got errors.
Not strange at all. It's an optional function in the UNIX/POSIX
standard, so only some systems provide it.
--
Geoff Clare <netnews@gclare.org.uk>
| |
| Jim Cochrane 2006-02-17, 10:40 pm |
| In article <pan.2006.02.17.13.34.33.616881@leafnode-msgid.gclare.org.uk>, Geoff Clare wrote:
> "Steven Woody" <narkewoody@gmail.com> wrote, on Fri, 17 Feb 2006:
>
>
> Not strange at all. It's an optional function in the UNIX/POSIX
> standard, so only some systems provide it.
>
On my FC4 system, I see:
man timer_create
TIMER_CREATE(P)
NAME
timer_create - create a per-process timer (REALTIME)
SYNOPSIS
#include <signal.h>
#include <time.h>
int timer_create(clockid_t clockid, struct sigevent *restrict evp,
timer_t *restrict timerid);
DESCRIPTION
The timer_create() function shall create a per-process timer using the
specified clock, clock_id, as the timing base. The timer_create() func-
tion shall return, in the location referenced by timerid, a timer ID of
type timer_t used to identify the timer in timer requests. This timer
ID shall be unique within the calling process until the timer is
deleted. The particular clock, clock_id, is defined in <time.h>. The
timer whose ID is returned shall be in a disarmed state upon return
from timer_create().
....
--
Jim Cochrane; jtc@dimensional.com
[When responding by email, include the term non-spam in the subject line to
get through my spam filter.]
| |
| Norman Black 2006-02-17, 10:40 pm |
| >> See setitimer(2) and timer_create(3).
>
> it's strange that my linux gets no timer_create(). i run man 3
> timer_create or man 2 timer_create(), but both got errors.
I have been using timer_create for ages and I started using Linux at the 2.2
kernel era. If man does not have it that does not mean that it is not
implemented. Check the headers. I have rarely used man. I normally look at
the Single Unix specification for API documentation.
Norman
|
|
|
|
|