In theory this general approach might have worked on. e.g., Solaris 10 and AIX.
In practice the handler code was Windows only, and there are good reasons
not to do it this way.

First, it's not clear asynchronous I/O is any win at all under modern
conditions. The disadvantage is that it's a complexity and defect
attractor; the advantage is reducing average latency and jitter due to
processing time in a synchronous I/O loop. In past times, with slower
processors, this was a serious issue.

But in 2016 we know from field experience that synchronous I/O produces
good NTP performance on Unix systems that don't do asynchronous
I/O.  Thus, it can be dropped.

If the standards for "good performance" rise to the point where we
want asynchronous I/O again, the right way to do it will not with
an OS-specific extension but with POSIX threads or some other
portable mechanism.