On Thu, Apr 15, 2010 at 10:01:31PM +0200, Nguy�n Thái Ng�c Duy wrote:
> +static void stop_timer_thread(void)
> +{
> + if (timer_event)
> + SetEvent(timer_event); /* tell thread to terminate */
> + if (timer_thread) {
> + int rc = WaitForSingleObject(timer_thread, 1000);
> + if (rc == WAIT_TIMEOUT)
> + fprintf(stderr, "timer thread did not terminate
> timely");
I'm not sure of the Win32 semantics on threads and objects, but isn't
there a race condition here? If high system load means that timer_thread
isn't scheduled to run before this times out, then this function could
first return (and when it does, it's safe for the caller to invalidate
the timer_fn callback), and then the timer_thread is finally scheduled,
calling the now-invalidated timer_fn callback.
> + else if (rc != WAIT_OBJECT_0)
> + fprintf(stderr, "waiting for timer thread failed: %lu",
> + GetLastError());
> + CloseHandle(timer_thread);
> + }
> + if (timer_event)
> + CloseHandle(timer_event);
> + timer_event = NULL;
> + timer_thread = NULL;
> +}
[...]
> +int sigaction(int sig, struct sigaction *in, struct sigaction *out)
> +{
> + if (sig != SIGALRM) {
> + errno = EINVAL;
> + return -1;
> + }
> + if (out != NULL) {
> + errno = EINVAL;
> + return -1;
> + }
It would be a good idea to check in->sa_flags and err out if != 0.
> +
> + timer_fn = in->sa_handler;
> + return 0;
> +}
>>> Dan
--
http://www.MoveAnnouncer.com The web change of address service
Let webmasters know that your web site has moved
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
