bug#22789: 25.1.50; In last master build https connections stop working

[Eli Zaretskii <eliz@gnu.org>]

> From: Alain Schneble <a.s@realize.ch>
> CC: <larsi@gnus.org>, <j_l_domenech@yahoo.com>, <22789@debbugs.gnu.org>
> Date: Mon, 7 Mar 2016 09:49:00 +0100
> 
> >                (I'll try to search the wisock documentation tomorrow to
> > find some hints that lead in this direction, or maybe you know?)
> 
> IIUC, this could be the reason why it fails:
> 
> - The reader_thread in w32proc.c calls _sys_wait_connect which in turn
>   does a WSAEventSelect.
> 
> - The documentation says:
> 
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms738573(v=vs.85).aspx
> 
>   The WSAAsyncSelect and WSAEventSelect functions automatically set a
>   socket to nonblocking mode.  If WSAAsyncSelect or WSAEventSelect has
>   been issued on a socket, then any attempt to use ioctlsocket to set
>   the socket back to blocking mode will fail with WSAEINVAL.
> 
> - So there /is/ a dependency between these calls.  Unfortunately, I
>   couldn't see that ioctlsocket returns with WSAEINVAL in the scenarios
>   I tried.

Yes, I know about this gotcha.  It's just that it never produced any
problems, and I never was able to see the ioctlsocket call fail with
WSAEINVAL.

>   Could it be a multi-threading issue then?  Multiple threads
>   accessing the same socket...

Not sure I follow -- are you trying to explain why ioctlsocket doesn't
fail as expected, or are you trying to explain some other phenomenon?

>   I don't see how both threads are synchronized.

The synchronization is between reader_thread and sys_select.  The
latter runs in the main (a.k.a. "Lisp") thread, the same thread where
sys_write is called.

>   The patch I sent would synchronize them through the FILE_CONNECT
>   flag, I think.  Did I miss something?

Well, that's not really "thread synchronization", but see my comments
and questions there.

Thanks.