[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: Eric Blake
Subject: Re: blocking socket is nonblocking after calling gnulib select() in windows
Date: Wed, 20 Apr 2011 15:53:38 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110318 Red Hat/3.1.9-3.el6_0 Mnenhy/0.8.3 Thunderbird/3.1.9

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

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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