Re: [PATCH 5/4] run-command: implement abort_async for pthreads

On Fri, Apr 1, 2011 at 11:16 PM, Jeff King [off-list ref] wrote:

On Fri, Apr 01, 2011 at 10:31:42PM +0200, Erik Faye-Lund wrote:

quoted

On Fri, Apr 1, 2011 at 10:18 PM, Johannes Sixt [off-list ref] wrote:

quoted

On Freitag, 1. April 2011, Erik Faye-Lund wrote:

quoted

On Fri, Apr 1, 2011 at 9:42 PM, Johannes Sixt [off-list ref] wrote:

quoted

But this does not help the case at hand in any way. How would you
interrupt a thread that is blocked in ReadFile()? The point of
pthread_cancel() is that it interrupts blocked system calls

There is no mention of such a guarantee in POSIX (section 2.9.5 Thread
Cancellation), so relying on that is undefined behavior.

In the paragraph before the bulleted list at the end of "Cancellation Points":

"...If a thread has cancelability enabled and a cancellation request is made
with the thread as a target while the thread is suspended at a cancellation
point, the thread shall be awakened and the cancellation request shall be
acted upon..."

A blocking thread and a suspended are two different matters. A
suspended thread is a thread that has been explicitly suspended by
wait, waitpid, sleep, pause etc. These functions explicitly say that
they suspend the thread ("shall suspend the calling thread until"),
while read etc does not ("shall block the calling thread until").

Similarly, making a blocking read/write fail (or terminate mid-way) is
not the same thing as awakening the thread.

I see how some people can read something like this into this section,
but I think it's pretty clear - this is not what it's talking about.
In fact, the more I read the relevant texts, the more convinced I get
that implementations that does terminate read/write strictly speaking
is in violation of the standard.

What about the text right before the bit that Johannes quoted:

 The side effects of acting upon a cancellation request while suspended
 during a call of a function are the same as the side effects that may
 be seen in a single-threaded program when a call to a function is
 interrupted by a signal and the given function returns [EINTR]. Any
 such side effects occur before any cancellation cleanup handlers are
 called.

Yeah, this is much closer, because it explicitly defines the behavior
to "fail" in the same way as when a signal interrupts a wait (which is
not simply awakening the thread). The text has the same problem for
this purpose as the one Johannes quoted; it talks about suspension,
not necessarily blocking. But it's mention of side-effects makes me
suspect that they mean blocking when they say suspension in this case,
because none of the functions that are documented as "blocking" seems
to have any side-effects in this case.

So yes, I think this is the most reasonable interpretation of this
paragraph. Thanks for making me re-read it :)

I agree it would be nicer if it explicitly said "when you are in a
function which is a cancellation point, pending cancellation requests
which are delivered are acuted upon immediately".

But it is implied to me by the surrounding text, and it's the only
sensible behavior IMHO.

I tend to agree with you on this.

Plus it seems to be what at least glibc pthreads
does on Linux, so I'm going to assume that people smarter than me
thought about it and came up with the same interpretation.

My test program was:

-- >8 --
#include <pthread.h>
#include <unistd.h>
#include <stdio.h>

void *child(void *data)
{
 char buf[32];
 int r;

 fprintf(stderr, "child reading from stdin...\n");
 r = read(0, buf, sizeof(buf));
 fprintf(stderr, "child read returned %d\n", r);
 return NULL;
}

int main(void)
{
 pthread_t t;
 void *r;

 pthread_create(&t, NULL, child, NULL);
 sleep(3);
 pthread_cancel(t);

 pthread_join(t, &r);
 if (r == PTHREAD_CANCELED)
   fprintf(stderr, "thread was canceled\n");
 else
   fprintf(stderr, "thread returned %p\n", r);

 return 0;
}
-- >8 --

If you input something before 3 seconds is up, the thread prints its
message and returns NULL. But if you let it go, the cancel interrupts
the read().

I'm not sure I agree that measured behavior is the same as defined
operation. But it does support the best theory we have.

So now we're left to figure out how to safely terminate a blocking
read on versions of Windows earlier than Windows Vista. Perhaps just
letting it time-out (assuming it does), and handle the cancellation at
the end of read() is acceptable (when there's no support for
CancelSynchronousIo, that is)? After all, this deadlock hasn't been
observed on threaded implementations making this issue kind of
theoretical on Windows, no? Also, this seems to be roughly how
pthreads-win32 implements cancellation...