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

[Erik Faye-Lund <kusmabite@gmail.com>]

On Fri, Apr 1, 2011 at 10:36 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Freitag, 1. April 2011, Erik Faye-Lund wrote:
>> On Fri, Apr 1, 2011 at 10:05 PM, Jeff King <peff@peff.net> wrote:
>> > On Fri, Apr 01, 2011 at 09:57:14PM +0200, Erik Faye-Lund wrote:
>> >> > 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.
>> >
>> > Eh? My pthreads(7) says that read() is required to be a cancellation
>> > point acrroding to POSIX. I didn't dig up the actual reference in the
>> > standard, though.
>>
>> I don't understand where the implementor would get that from after
>> reading through it, but if there's something I've missed we can fix it
>> by replacing my pthread_cancel with this, no?
>>
>> static inline int pthread_cancel(pthread_t thread)
>> {
>>       SetEvent(thread.cancel_event);
>>       CancelSynchronousIo(thread.handle);
>> }
>
> Do I deserve this? There *is* a function that does what we need. I get what I
> deserve when I don't study all 100,000 functions in the manual...
>

Hey, it's mentioned in the ReadFile documentation!

> Wait a minute! I *did* study 100,000 functions. This is one of the 25,000
> functions that are new in Vista... Those I haven't studied, yet.
>

Bah, Vista and up. That blows, we support WinXP as well! Well,
dynamically loading the function when it's there is better than doing
NOTHING, which was the previous alternative, no? :)