Re: pthread_cond_timedwait() bug in Tiger?
site_archiver@lists.apple.com Delivered-To: Darwin-dev@lists.apple.com For posterity: matt. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Could it be that there is a bug in pthread_cond_timedwait() that causes it to block forever if the absolute time value passed to it lies in the past? Hi, sorry for taking so long to follow up with this. I've been a little busy. Yes, there appears to be a bug in this routine in Tiger when either _XOPEN_SOURCE, _POSIX_C_SOURCE or _APPLE_C_SOURCE is defined at compile time, and you pass in an already elapsed timeout at runtime. As a workaround, you can use pthread_cond_timedwait_relative_np() and pass in a relative timeout, rather than computing the absolute timeout. This email sent to site_archiver@lists.apple.com
participants (1)
-
Matt Watson