time returning -1

[Servé Lau]

I encountered a situation today where time(NULL) returned -1. This was
because at the point of the call the function could not read from the bus
because it was locked by another process.
I got the advice to use while((t = time(NULL)) == -1) { ; }

I always thought that time only returned -1 when their was no timer
functionality in the hardware and that it should return a valid value for
all other cases. Is that correct? Should the loop above be moved into the
time function?

[Eric Sosman]

Servé Lau wrote:

I encountered a situation today where time(NULL) returned -1. This was
because at the point of the call the function could not read from the bus
because it was locked by another process.
I got the advice to use while((t = time(NULL)) == -1) { ; }

I always thought that time only returned -1 when their was no timer
functionality in the hardware and that it should return a valid value for
all other cases. Is that correct? Should the loop above be moved into the
time function?

time() returns -1 "if the calendar time is not available."
There are many reasons the calendar time might be unavailable:
no timer in the system, timer reading outside the time_t range,
timer temporarily unavailable, ... The Standard does not try
to enumerate all the failure modes.

Does the loop belong inside time()? I think not. If the
time is unavailable, there's no guarantee that it will become
available within a reasonable, er, time. Maybe the hardware
timer has "locked up" somehow and will not recover until it's
been power-cycled and reset. Maybe the other process that's
interfering with your time() calls will keep on interfering
with them until somebody kills it. Would you rather receive
a failure indication, or just have your program freeze inside
the time() function?

--
Er*********@sun.com

[Keith Thompson]

"Servé Lau" <bl****@bleat.com> writes:

I encountered a situation today where time(NULL) returned -1. This was
because at the point of the call the function could not read from the bus
because it was locked by another process.
I got the advice to use while((t = time(NULL)) == -1) { ; }

I always thought that time only returned -1 when their was no timer
functionality in the hardware and that it should return a valid value for
all other cases. Is that correct? Should the loop above be moved into the
time function?

Eric Sosman's reply was good Also, a tight loop like that is likely to
be a bad idea on a multi-process system; your program will gobble CPU
time at the expense of other processes until the time becomes
available. It might even prevent the other process from releasing its
lock on the bus.

It probably makes sense for something like the loop to be inside the
time() function *if* it can determine that the failure is a temporary
one. Ideally, there should be some way for time() to go to sleep
until the information becomes available, allowing other processes to
run.

This is all extremely system-specific, of course. The C standard
doesn't deal with multiple processes, and as far as it's concerned the
time() function either succeeds or fails.

You might consider putting a short delay into your loop (in some
system-specific way), and perhaps bailing out with an error indication
if time() fails too many times in a row.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Lawrence Kirby]

On Wed, 20 Apr 2005 12:57:19 -0400, Eric Sosman wrote:

Servé Lau wrote:

I encountered a situation today where time(NULL) returned -1. This was
because at the point of the call the function could not read from the bus
because it was locked by another process.
I got the advice to use while((t = time(NULL)) == -1) { ; }

I always thought that time only returned -1 when their was no timer
functionality in the hardware and that it should return a valid value for
all other cases. Is that correct? Should the loop above be moved into the
time function?
time() returns -1 "if the calendar time is not available."
There are many reasons the calendar time might be unavailable:
no timer in the system, timer reading outside the time_t range,
timer temporarily unavailable, ... The Standard does not try
to enumerate all the failure modes.

Does the loop belong inside time()? I think not.

It depends, and requires implementation-specific knowledge. But of course
as time() is part of the implementation that's not a problem. If the
implementation knows that this bus locking is the source of the problem
and is a transient phenomenon it would make sense for it to loop in
time(). Programs that call time() typically don't deal with transient
failure of that function, if they test for failure at all. So if the
implementation can make "typical" programs continue to work correctly then
it probably should.

OTOH the implementor may have already considered this and decided that
it is not viable.
If the
time is unavailable, there's no guarantee that it will become
available within a reasonable, er, time.
The time() implementation could implement a timeout(!). But maybe it did
and has timed out. :-)
Maybe the hardware
timer has "locked up" somehow and will not recover until it's
been power-cycled and reset.
In which case the problem isn't transient and it wouldn't be useful for
the calling program to keep trying.
Maybe the other process that's
interfering with your time() calls will keep on interfering
with them until somebody kills it. Would you rather receive
a failure indication, or just have your program freeze inside
the time() function?

That would depend on various factors. A process that caused such
interference would likely be considered faulty. Again if the behaviour of
time() makes it necessary to create a calling loop in the user code it
isn't helping. If a system can get into a state where a bus is locked
indefinitely then the system is probably not usable from that point on.

Lawrence