win: cause uv_read_stop to immediately stop reading the stream

this implements locking around the blocking call to ReadFile to get
around a Windows kernel bug where a blocking ReadFile operation on a
stream can deadlock the thread. this allows uv_read_stop to immediately
cancel a pending IO operation, and allows uv_pipe_getsockname to
"pause" any pending read (from libuv) while it retrieves the
sockname information

if unsupported by the OS (pre-Vista), this reverts to the old
(e.g. deadlock-prone) behavior

ref. issue #1313
On 08/05/2014 02:36 AM, Jameson Nash wrote:
> In src/win/pipe.c:
> 
>> @@ -657,12 +675,40 @@ void uv_pipe_connect(uv_connect_t* req, uv_pipe_t* handle,
>>    return;
>>  }
>>  
>> +uv_mutex_t *uv_pipe_readfile_pause(const uv_pipe_t* handle) {
>> +  uv_mutex_t *m = handle->readfile_mutex;
>> +  if (m) {
>> +      /* Pause the ReadFile task briefly, to work
>> +         around the Windows kernel bug that causes
>> +         any access to a NamedPipe to deadlock if
>> +         any process has called ReadFile */
>> +      HANDLE h;
>> +      uv_mutex_lock(m);
>> +      h = handle->readfile_thread;
>> +      while (h) {
>> +        /* spinlock: we expect this to finish quickly,
>> +           or we are probably about to deadlock anyways
> 
> s/caouldn't/couldn't/ (sorry, couldn't help that either :P)
> 

Hahaha, touche! :-)


-- 
Saúl Ibarra Corretgé
bettercallsaghul.com