[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 22:17:39 +0200 |
On Thu, Apr 21, 2011 at 8:59 AM, Ray Satiro <address@hidden> 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
>>
>
> Hi, thanks for your replies guys.
>
> Bastien, The problem with sending io control codes is there will likely be
> unintended consequences if used as you theorize. From what I've seen so far
> there is no way to determine the blocking state without sending a control
> code,
> or in other words, actually making the request. If the socket is blocking then
> it will block. If blocking, killing the thread that's waiting on the event
> you'd
> be killing the waiting not the pending operation, although I haven't tested
> that
> so I can't say for certain.
>
> api monitor shows:
> Either SIO_ADDRESS_LIST_CHANGE or SIO_ROUTING_INTERFACE_CHANGE will result in
> ntdeviceiocontrol(socket, event, ...
> If the socket is nonblocking the immediate return is STATUS_DEVICE_NOT_READY.
> If
> it is blocking then the immediate return is STATUS_PENDING and wsaioctl
> waits
> for a signal which is set when the operation completes.
>
> I think for now I will submit code for Wget that will disable NBIO immediately
> after rpl_select() returns or instead use ms select() with FD_TO_SOCKET.
>
>
> Thanks,
What give FILE_MODE_INFORMATION query using NtQueryInformationFile on
(Handle) Socket ?
Bastien
- Re: blocking socket is nonblocking after calling gnulib select() in windows, (continued)
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Bruno Haible, 2011/04/19
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Bastien ROUCARIES, 2011/04/20
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Bastien ROUCARIES, 2011/04/20
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Eric Blake, 2011/04/20
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Bastien ROUCARIES, 2011/04/20
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Bastien ROUCARIES, 2011/04/20
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Paolo Bonzini, 2011/04/21
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Ray Satiro, 2011/04/21
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Bastien ROUCARIES, 2011/04/21
- Re: blocking socket is nonblocking after calling gnulib select() in windows,
Bastien ROUCARIES <=
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Ray Satiro, 2011/04/22
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Paolo Bonzini, 2011/04/22