Error conditions, other considerations

Posted Sep 28, 2007 22:24 UTC (Fri) by filker0 (guest, #31278)
Parent article: The new timerfd() API

I have not followed this, and my quick tracing of articles didn't lead to answers to a few questions that I have.

What error is returned if a non-timer fd is used in a call to timerfd_settime() or timerfd_gettime()?
What error is returned (if any) when a timer fd is passed to close()?
Are the timer fds unique across the entire system?
Are timer fds inherited or duplicated across a fork? Exec?
Are timers destoryed when the process ends?
Can one process set a timer for another?

If the answer to #6 is "Yes", it would introduce a nice IPC mechanism that I could see being useful in GUI, simulation, and automated test software. Of course, the answer to #6 depends on #s 3 and 4. Also, certain of these would have security implications as well.

I suppose I ought to get a recent kernel source distro, apply the proposed patches, then search out the man page, look at the implementation, and see if I can find any flaws in the API that should be addressed.

to post comments

Error conditions, other considerations

Posted Oct 3, 2007 21:18 UTC (Wed) by mkerrisk (subscriber, #1978) [Link] (1 responses)

The right place to ask these (good) questions is of the developer, on the kernel mailing list. But, here goes:

> 1. What error is returned if a non-timer fd is used in a
> call to timerfd_settime() or timerfd_gettime()?

I have not tested this, but it should give EINVAL.

> 2. What error is returned (if any) when a timer fd is passed to close()?

That is not an error. See the man page:
http://thread.gmane.org/gmane.linux.kernel/584510

> 3. Are the timer fds unique across the entire system?

No.

> 4. Are timer fds inherited or duplicated across a fork? Exec?

Yes and yes.

> 5. Are timers destroyed when the process ends?

The file descriptor is closed. If some other process has a file descriptor (because of fork(), for example), then I believe the timer should continue to exist. This should be tested.

> 6. Can one process set a timer for another?

See 5.

Thanks for the pointer

Posted Oct 4, 2007 1:50 UTC (Thu) by filker0 (guest, #31278) [Link]

Thanks for the response. I'd not seen the manpage before. I'm not on the kernel mailing list due
to lack of time right now.

I did some development on an embedded kernel some years ago that had a feature similar to
these timers. They could be annonymous (not visible to other tasks) or named. Named timers
persisted from creation to the end of time (well, until you shut down or reset the box) -- it was
an embedded system, we didn't need to delete them. A named timer could be created and set,
then closed. Any task could open the timer and do a blocking read, which would block the task
until it expired, or a non-blocking read which would return the number of days/hours/minutes/
seconds/ticks until the next expiration, additional reads would return the next expiration after
that, and so on. A blocked task could be awaken from a read by an AST (asynchronous system
trap, this was more RSX than Unix like). You set the timer by writing to it (it was a binary
structure that contained timer information). Timers could be set using relative or absolute time,
and could have single or repeating events, and you could have up to 8 events of any type queued
up in a timer. Each event structure also had a chain of completion and cancellation callbacks
that could, in theory, be arbitrarily long. Since it was an embedded system, we provided no real
protection on these things, and if you scheduled a callback from your task and then terminated,
the callback would still get called unless you cancelled it before termination.

It was a very useful and somewhat nifty system for inter-task synchronization in a mostly
asynchronous application (a high end video terminal).

Anonymous timers were pretty much the same except that they were destroyed when your task
exited and were not visible to other tasks. We didn't have fork(), nor exec() as Unix/Linux has
them, so nothing ever got inherited. All the code on the system was always there (we ran out of
ROM), and a task was just a thread of execution that was started with a system call.

Anyway, thanks again for the response.