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
