[prev in list] [next in list] [prev in thread] [next in thread] 

List:       classiccmp
Subject:    Re: Der Mouse
From:       der Mouse <mouse () rodents ! montreal ! qc ! ca>
Date:       2005-04-30 23:02:07
Message-ID: 200504302317.TAA03748 () Sparkle ! Rodents ! Montreal ! QC ! CA
[Download RAW message or body]

>>> "timer sockets" (PF_TIMER)
>> Briefly, they provide a file-descriptor interface to the timer
>> facilities underlying setitimer(ITIMER_REAL) and SIGALRM.
> OK, but I still don't understand what problem they solve.

Like a lot of facilities, they're a matter of convenience.

If your program uses timer signals *in order to* interrupt operations
in progress, you want signals - you want setitimer() and sigaction().

But if your program uses timer signals merely to drive time-based
processing, such as a game that wants to do something ten times a
second and doesn't want to interrupt other processing, merely wanting
to set a flag which is checked to see if it's time to do whatever -
then timer sockets can help.  Instead of having a signal handler set a
flag which you check in your main loop, instead, you create a timer
socket and check its file descriptor along with the descriptors you're
probably already checking for user input, maybe network connections if
it's over-the-net, that kind of thing.

> Well, maybe I have an idea.  The one program I used setitimer() in
> would core dump if the system was heavily loaded and a second timer
> signal occurred before service for an earlier one completed.  Does
> the file descriptor interface solve this somehow?

Yes - because it doesn't use signals.

Rather, you create a timer socket

	ts = socket(AF_TIMER,SOCK_STREAM,0);

and you set its timer with

	struct itimeval itv;
	...set up itv...
	/* old way setitimer(ITIMER_REAL,&itv); */
	write(ts,&itv,sizeof(itv));

and then, rather than getting a signal, the timer socket "receives"
"input": it becomes readable, and if you read from it you get a struct
which describes the event (usually a timer event, in which case it
holds the time at which the event nominally occurred, but it can also
be an error event if an error condition arose).

Timer sockets are also useful because you can have a more or less
unlimited number of them, whereas there's only one ITIMER_REAL.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
[prev in list] [next in list] [prev in thread] [next in thread]