Hi Vladislav,
On 11/19/10 9:48 AM, Vladislav Vaintroub wrote:
>
>
>> -----Original Message----- From: Davi Arnaut
>> [mailto:davi.arnaut@stripped] Sent: Friday, November 19, 2010
>> 12:03 PM To: Vladislav Vaintroub Cc: commits@stripped
>> Subject: Re: bzr commit into mysql-5.5-runtime branch (davi:3186)
>> Bug#54790
>
> Hi Davi
>
>> Hi Vladislav,
>>
>> On 11/19/10 6:01 AM, Vladislav Vaintroub wrote:
>>
>
>
>> The Winsock documentation says that after a I/O is canceled on a
>> socket, the socket is left in a undefined state. It can only be
>> closed after that.
>
> I would like to have a URL to that documentation.
http://msdn.microsoft.com/en-us/library/ms740087(VS.85).aspx
More specifically, this paragraph:
"In many cases, Winsock overlapped operations using AcceptEx, ConnectEx,
WSASend, WSARecv, TransmitFile, and similar functions are cancelable.
However, behavior is undefined for the continued use of a socket that
has canceled outstanding operations. The closesocket function should be
called after canceling an overlapped operation. Therefore, for best
results, instead of canceling the I/O directly, the closesocket function
should be called to close the socket which will eventually discontinue
all pending operations."
>>
>
>>> end up with WaitForSingleObject in an optimized version.
>>
>> Asynchronous I/O is nice and all, but its not viable to change the
>> server design to adapt to the pattern of overlapped I/O. We should
>> be looking for alternative that fit our pattern, not the other way
>> around.
>
> The only thing we can have is poll()..Everything that can come from
> Unix is poll(), it does not have anything else (ok , it can have
> good poll like epoll and bad poll like select) and but there is no
> good poll on Windows and will not ever be.
There is WSAEventSelect...
>> I actually like asynchornous I/O and I'm a big fan of completion
>> ports. Most of my projects which start from zero are based around
>> asynchronous event loops. But they don't quite fit the MySQL I/O
>> model. They were designed for other type of applications.
>
> I was not talking real async IO, merely as a tool to emulate
> interruptible, and timeout-able blocking socket operation. As I
> understand we need that only, and poll() is also a tool and it is not
> a fact it is a good one.
Yes, it is very good when done properly. But you are changing the
subject. Again, you seen to be too concerned about poll().
I repeat, the important thing is to come up with a interface that meets
the server design. Whether that is poll, overlapped I/O or pigeons is
only a consequence of which one fits our problem best.
Regards,
Davi
