信号处理程序中time（）的time_t值不正确 [英] Incorrect time_t value from time() in signal handler
问题描述
我在time.h中使用time（）函数时发现了一个奇怪的行为。
有时在调用它时，它会没有在
秒内显示正确的时间，而是初始值。这次似乎是第一次启动
计划的时间。
我的平台是装有Tru64的DEC机器。
可能的解释是，在信号处理程序中调用time（）函数
。该程序使用SIGTIME通过程序定期运行
。有一些带有时间戳的日志条目已经完成。
这些时间戳有时是错误的。
我的问题是，如果有人知道，在什么情况下时间（）
函数可以产生不正确的值，如果有一些
效果。
提前谢谢，
Sven Bauhan
Hi,
I found a strange behaviour when using the time() function from time.h.
Sometimes when it is called, it does not show the correct time in
seconds, but an initial value. This time seem to be the time when the
program was started the first time.
My platform is a DEC machine with Tru64 onboard.
A possible explanation could be, that the time() function is called
within a signal handler. The program uses a SIGTIME to run regularly
through a procedure. There some log entries with time stamp are done.
These time stamps are sometimes wrong.
My question is, if someone knows, under which circumstances the time()
function can produce incorrect values and if there are some side
effects.
Thanks in advance,
Sven Bauhan
推荐答案
Sven写道：
Sven wrote:
我在time.h中使用time（）函数时发现了一个奇怪的行为。
有时当它被称为，它没有显示
秒的正确时间，而是初始值。这次似乎是第一次启动
计划的时间。
我的平台是装有Tru64的DEC机器。
可能的解释是，在信号处理程序中调用time（）函数
。该程序使用SIGTIME通过程序定期运行
。有一些带有时间戳的日志条目已经完成。
这些时间戳有时是错误的。
我的问题是，如果有人知道，在什么情况下时间（）
函数可以产生不正确的值，如果有一些
效果。
提前谢谢，
Sven Bauhan
Hi,
I found a strange behaviour when using the time() function from time.h.
Sometimes when it is called, it does not show the correct time in
seconds, but an initial value. This time seem to be the time when the
program was started the first time.
My platform is a DEC machine with Tru64 onboard.
A possible explanation could be, that the time() function is called
within a signal handler. The program uses a SIGTIME to run regularly
through a procedure. There some log entries with time stamp are done.
These time stamps are sometimes wrong.
My question is, if someone knows, under which circumstances the time()
function can produce incorrect values and if there are some side
effects.
Thanks in advance,
Sven Bauhan
本身不是C问题，但是：
您是否将此链接与线程安全的库？任何时候你都有异步信号消失，你需要一个线程安全的（或实际上，
可重入安全的）程序和库。
另请注意，time（）在静态位置返回其值。如果
你在定时器信号函数中这样做，你可能会覆盖你在其他地方获得的时间值。
你也检查返回值，看它是否返回
错误代码（（time_t）-1）??
有时你有信号关闭，库例程和系统
调用随机返回INTERRUPTED_SYSTEM_CALL。你必须
假设每次通话都可能失败，并检查是否有失败。许多图书馆和
系统通话都不会失败，如果你有定时器的话，可能会失败。尝试禁用你的计时器，看看time（）问题是否会消失。这会让你觉得这是一个与定时器信号有关的问题。
not a C question per se, but :
Are you linking this with the thread-safe library? Anytime you have
asynchronous signals going off, you need a thread-safe (or actually,
reentrant-safe) program and library.
Also note that time() returns its value in a static location. If
you''re doing this inside the timer signal function, you may be
overwriting the time value you got in other places.
Also are you checking the return value to see if it is returning an
error code ((time_t)-1) ??
Sometimes when you have signals going off, library routines and system
calls return INTERRUPTED_SYSTEM_CALL at random times. You have to
assume every call might fail, and check for failure. Many library and
system calls that don''t fail normally can fail if you have timers going
off. Try disabling your timers and see if the time() problem goes
away. That would point you to this being a timer signal related
problem.
我也遇到了信号处理方面的问题。 br />
使用fprintf（）调用进行跟踪（当然获得了额外的时间信息），系统（Fedora FC3）将进入
死锁情况，因为fprintf（）会调用内部相互的
排除锁定（mutex-operation）。我们得到了类似的情况
在SUN / solaris。
一个好的建议是，从不通过信号调用任何系统功能
处理程序。改为设置一个全局标志或计数器，并在主循环中查看全局
标志/计数器（如果有的话）。
我不喜欢我知道，如果线程安全的功能可以解决这个问题。
I have some problems with signal handling too.
Using a fprintf() call for tracing (of course with getting an
additional time information), the system (Fedora FC3) will get into a
deadlock situation, because the fprintf() will call an internal mutual
exclusion locking (mutex-operation). We got quite a similar situation
at SUN/solaris.
A good proposal is, never call any system function out of a signal
handler. Set a global flag or counter instead, and check the global
flag/counter at a main loop (if you have any).
I don''t know, if the thread-safe functions can solve this problem.
Ancient_Hacker写道：
Ancient_Hacker wrote:
您是否将此链接与线程安全库？任何时候你都有异步信号消失，你需要一个线程安全（或实际上，
可重入安全）程序和库。
Are you linking this with the thread-safe library? Anytime you have
asynchronous signals going off, you need a thread-safe (or actually,
reentrant-safe) program and library.
我该怎么做？这只是一个链接器选项吗？
How do I have to do this? Is this just a linker option?
另请注意，time（）在静态位置返回其值。如果
你在定时器信号函数中这样做，你可能会覆盖你在其他地方获得的时间值。
Also note that time() returns its value in a static location. If
you''re doing this inside the timer signal function, you may be
overwriting the time value you got in other places.
这没问题，我打电话给：
time_t tVal;
time（& tVal）;
That is no problem, I call:
time_t tVal;
time( &tVal );
你还检查返回值，看它是否返回了
错误代码（（time_t）-1）??
Also are you checking the return value to see if it is returning an
error code ((time_t)-1) ??
我看到了这个，但（（time_t）-1）是什么意思？
参数中给出的值是否减少了一个？
time_t tVal = 1;
if（！time（& tVal））{/ * error * /}
我不能离开计时器，因为没有计时器，程序
就没有意义了。
Sven
I saw this, but what does ((time_t)-1) mean?
Is this the value given in the parameter decreased by one?
time_t tVal = 1;
if ( ! time( &tVal ) ) { /* error */ }
I cannot leave the timer away, because without the timer the program
would make no more sense.
Sven
这篇关于信号处理程序中time（）的time_t值不正确的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
