[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Bastien ROUCARIES
Subject: Re: blocking socket is nonblocking after calling gnulib select() in windows
Date: Thu, 21 Apr 2011 00:15:45 +0200

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
>>> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]