site_archiver@lists.apple.com Delivered-To: Darwin-kernel@lists.apple.com User-agent: Alpine 1.00 (DEB 882 2007-12-20) Hi Terry, On Tue, 2 Mar 2010, Terry Lambert wrote: Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... The comment in the Libc code about the layout isn't strictly correct. Specifically, the ADD_MACH_TIMESPEC() and SUB_MACH_TIMESPEC() are macros, and the marcros only really care about having a corresponding field name for tv_nsec and tv_usec in the structures, so the difference in element size in the structure isn't going to matter, at least until we hit Y2038. Unfortunately I think it does matter, as I suspect that the resulting conversion from signed to unsigned and back is the cause of a wrong value being returned in the remaining time structure. Any ideas why I'm seeing (1<<32)-1 in tr.tv_sec after the call, when the call finishes late? This is the actual problem that I'm having. The base problem causing the issue is the signal handler taking a very long time to run in the test code. I have been able to reproduce the problem with an empty signal handler, provided that the timing of the signal arrival is just right (probably as the SEMWAIT_SIGNAL is just about to finish). Meanwhile, you should file a bug, and include this conversation as part of your description. The component it needs to be filed against is Libc. Thanks for your advice and encouragement. I have filed the report as bug number 7718487. This email sent to site_archiver@lists.apple.com