Briefly, they provide a file-descriptor interface to the timer facilities underlying setitimer(ITIMER_REAL) and SIGALRM. On recent NetBSD, I think kqueue may be able to be substitute for them, but I don't know it well enough to be sure. (Also, I did AF_TIMER long before kqueue came in, and more than half as an exercise in adding a new socket family.) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Depends on what you mean. If you mean "in response to an asynchronous external condition", no, they don't. If you mean "in response to one of various timeouts expiring", yes, they do, if you throw the timer socket file descriptor(s) into the select set. Yes. That's another reason I find them useful - you don't have to keep your own list of timers and constantly pick out the next one to expire, simplifying code. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

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. 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 at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B