Re: blocking socket is nonblocking after calling gnulib select() in windows

[Bastien ROUCARIES]

On Wed, Apr 20, 2011 at 11:53 PM, Eric Blake <address@hidden> wrote:
> On 04/20/2011 03:46 PM, Bastien ROUCARIES wrote:
>> On Wed, Apr 20, 2011 at 7:17 PM, Bastien ROUCARIES
>> <address@hidden> wrote:
>>>> Is the gnulib select() only intended to be used with nonblocking sockets on
>>>> windows?
>>>
>>> I have just tested the program at the end of the file, it thread is
>>> blocked when enable =0 (block socket) and enable=1 it fail with
>>> WSAEWOULDBLOCK
>>>
>>> So i possible stragegy will be:
>>> 1. createathread TID from parent
>>> 2. in TID do WSAIoctl(sock, SIO_ADDRESS_LIST_CHANGE,NULL, 0, NULL,
>>> 0,&bytes,NULL,NULL);
>>> 3. in  parent: if TID returned with WSAEWOULDBLOCK tag socket non blocking
>>> 4. query running state of TID, if suspended socket is blocking, kill
>>> thread and mark socket blocking
>>
>> It will not work using a thread (thread are not cancelable under
>> windows), but using a new process with inherited socket it will work
>> slow but a little bit as the projected openat function using fork
>
> Spawning a process just to learn if a socket is blocking?  Wow.
>
> Sounds like caching the information independently (like we already do
> for dirfd) is the way to go then, so that we only have to spawn when
> inheriting sockets through stdin/out/err.


That is the idea.... But at least we know is a socket is blocking or not

Another one is to use
http://www.codeproject.com/KB/threads/QueueUserAPCEx_v2.aspx

Bastien

Bastien