Message-ID: <4FB62304.2000100@sister-shadow.de>
Date: Fri, 18 May 2012 12:23:00 +0200
From: Otto Meta <otto DOT meta AT sister-shadow DOT de>
Reply-To: cygwin AT cygwin DOT com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: 1.7.15-1: pthread_cancel and pthread_kill not working as expected
References: <4FAAAE25 DOT 40204 AT sister-shadow DOT de>
In-Reply-To: <4FAAAE25.40204@sister-shadow.de>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Greetings,

as I got no response to my first question, I tried two older Cygwin
versions to narrow down the problem. Maybe this’ll help someone to
figure out the cause.

I tried 1.7.9 and 1.7.12-1, with the results of 1.7.12-1 being exactly
like the ones from 1.7.14-2 and 1.7.15-1. Unfortunately I couldn’t dig
up any versions between 1.7.9 and 1.7.12-1.

Results from 1.7.12-1 (for semaphores, detailed results in my last mail):
Test 1: Main thread hangs on pthread_cancel() (PTHREAD_CANCEL_DEFERRED)
Test 2: Threads ignore pthread_cancel() (PTHREAD_CANCEL_ASYNCHRONOUS)
Test 3: Signals often wake the wrong thread
Test 4: Wrong thread wakes up once, then nothing
Test 5: Some threads exit, depending on whether the signal reached the
        right thread
Test 6: Thread isn't cancelled even after a waking it with a signal

On 1.7.9 things are a bit different:
Test 1: PTHREAD_CANCEL_DEFERRED
        semaphore/pause: All threads are cancelled via pthread_cancel()
        read: No thread is cancelled
Test 2: PTHREAD_CANCEL_ASYNCHRONOUS
        Threads ignore pthread_cancel()
Test 3: semaphore/read: No thread wakes up or executes the signal handler,
          sleep() doesn't sleep any more after the first signal (returns
          immediately)
        pause: All threads wake up on every signal, correct thread
          executes signal handler
Test 4: semaphore/read: No thread wakes up or executes the signal handler,
          sleep() doesn't sleep any more after the first signal (returns
          immediately)
        pause: All threads wake up on every signal, correct thread
          executes signal handler
Test 5: semaphore: No thread is killed, sleep() doesn't sleep any more
        pause: First thread cancelled, other threads won't pause()
          any more and run amok
        read: Some threads are killed, sleep() doesn't sleep any more
Test 6: semaphore/pause: No thread is killed, sleep() doesn't sleep
          any more
        pause: First thread cancelled, other threads won't pause()
          any more and run amok

Sorry if I’m mixing two (or three?) problems, but they all seem
pthreads-related.

pthread_cancel deferred:
Worked on threads blocked in sem_wait() and pause() in 1.7.9, doesn’t work
any more in 1.7.12-1 and newer and instead hangs calling thread. I’d
consider this one a regression. Didn’t work on threads blocked in read()
in any tested version.

pthread_cancel asynchronous:
No thread is cancelled in any tested version. Calling thread doesn’t hang,
though.

pthread_kill:
In 1.7.9 a signal to any thread wakes up all threads blocked in pause()
and the correct thread executes the signal handler. Doesn’t wake threads
blocked in sem_wait() or read(). After delivering a signal, pause() and
sleep() don’t block any more and return immediately.
In 1.7.12-1 and newer sleep() and pause() won’t break and not all threads
are woken up. Instead only one thread is woken, but unfortunately not
always the correct one.

While signal handling mostly seems to have improved, cancelling
got worse. Especially the fact that the calling thread blocks in
pthread_cancel can be quite a show-stopper.

Any suggestions or ideas?

Cheers,
Otto

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple