[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 10:32:35 +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, ...
Really nice to see that, ntdeviceiocontrol thread could be put in
alertable state and thus safely stopable by an APC.
If you could try direclty the ntdeviceiocontrol with the same flag we
could have some good clue.
Bastien
> 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,
>
> Jay
>
>
>
- Re: blocking socket is nonblocking after calling gnulib select() in windows, (continued)
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Bastien ROUCARIES, 2011/04/19
- 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 <=
- 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, Ray Satiro, 2011/04/22
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Paolo Bonzini, 2011/04/22