List:Commits« Previous MessageNext Message »
From:Davi Arnaut Date:November 19 2010 11:02am
Subject:Re: bzr commit into mysql-5.5-runtime branch (davi:3186) Bug#54790
View as plain text  
Hi Vladislav,

On 11/19/10 6:01 AM, Vladislav Vaintroub wrote:

[..]

>>
>> The alternative which I think is more sane and that shouldn't suck
>> too much performance wise is to use WSAEventSelect. But there is a
>> catch. The authors of the said function decided to make FD_READ
>> events special in the sense that they are level triggered, while
>> FD_WRITE events are edge triggered. Which leaves us with the choice
>> to either disable FD_READ events after each wait or to just let
>> them pending and use WSAEnumNetworkEvents after each wake up.
>
>
>
> Dunno, async io does not seem t be that complicated. Buffers are not
> going anywhere, we would not leave he functions with an incomplete
> io, would be too bad ..  Anyway my point is that  It  should be  easy
> to write a vio_read/vio_write ,  with timeouts and cancellation, with
> implementation a lot  sense of Linux-optimized MSG_DONTWAIT, but not
> using poll(), or its numerous incomplete Windows equivalents.  This
> would use asynchronous IO,  even if to user it  appears as normal
> blocking IO.  We talked before about this, I just guess I could
> formulate the idea bette, and understand it myself... Consider idea
> for  vio_read(),  with timeouts and cancel functionality:  start read
> operation  asynchronously, and then waits for io completion  or
> cancel event (real windows event object which can be signaled from
> outside) or for timeout. If  something bad happens, and  IO is in
> progress CancelIo .   I encourage you to find a bug in this logic,
> Icannot see yet how it could be bad. The "pro" argument is that
> should be faster than anything else, especially if IO does not
> block.
>

This is not a matter of finding a flaw in the logic. I think you are 
ignoring the requirements. We need the socket in a defined state after 
some other threads interrupts a I/O wait.

This is because in some cases, while deep in the optimizer and some 
other places, we still send a error message to the user after its 
connection has been killed.

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.

[..]

>
> The cancel functionality would be just int vio_cancel_io(Vio *io) {
> return SetEvent(io->cancel_event)?0:-1; }
>
> That's it , it can do read, timeout , can be interrupted.  It sucks
> somewhat , with  2 extra events per vio (cancel_event and one in
> overlapped).  On Vista, canceling from outside can be done more
> efficient using CancelIoEx.  Extra bonus point for using vio->sd in
> WaitForMultipleObjects, instead of , vio->overlapped->hEvent (yes,
> this surprisingly should work too,  overlapped with hEvent=NULL
> should signal the file handle  an one could wait for file handle,
> but I never had a chance to test in practice) . So we actually may
> 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.

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.

Regards,

Davi
Thread
bzr commit into mysql-5.5-runtime branch (davi:3186) Bug#54790Davi Arnaut16 Nov
Re: bzr commit into mysql-5.5-runtime branch (davi:3186) Bug#54790Davi Arnaut18 Nov
  • RE: bzr commit into mysql-5.5-runtime branch (davi:3186) Bug#54790Vladislav Vaintroub19 Nov
    • Re: bzr commit into mysql-5.5-runtime branch (davi:3186) Bug#54790Davi Arnaut19 Nov
      • RE: bzr commit into mysql-5.5-runtime branch (davi:3186) Bug#54790Vladislav Vaintroub19 Nov
        • Re: bzr commit into mysql-5.5-runtime branch (davi:3186) Bug#54790Davi Arnaut19 Nov
          • RE: bzr commit into mysql-5.5-runtime branch (davi:3186) Bug#54790Vladislav Vaintroub19 Nov
            • Re: bzr commit into mysql-5.5-runtime branch (davi:3186) Bug#54790Davi Arnaut19 Nov
            • Re: bzr commit into mysql-5.5-runtime branch (davi:3186) Bug#54790Davi Arnaut19 Nov
              • RE: bzr commit into mysql-5.5-runtime branch (davi:3186) Bug#54790Vladislav Vaintroub19 Nov
                • Re: bzr commit into mysql-5.5-runtime branch (davi:3186) Bug#54790Davi Arnaut19 Nov
                  • RE: bzr commit into mysql-5.5-runtime branch (davi:3186) Bug#54790Vladislav Vaintroub19 Nov
                    • Re: bzr commit into mysql-5.5-runtime branch (davi:3186) Bug#54790Davi Arnaut19 Nov
RE: bzr commit into mysql-5.5-runtime branch (davi:3186) Bug#54790Vladislav Vaintroub19 Nov