On Wed, 2 Sep 2009 10:32:41 -0500
Nicolas Williams <Nicolas.Williams at sun.com> wrote:
Absolutely no polling.
Async I/O is not rocket science. We can quibble over details, but we've
only got so many workable models. And we have to be mindful that not
one model will result in fully portable application code.
Here are some reasonable models:
- Completion callback (or, rather, a callback indicating that there's
work to do, not necessarily completion)
This implies either a threaded process model or an async I/O process
model with one common event loop provided by the OS.
This model is the simplest for apps to use, and it will be portable
to Linux, *BSD, Solaris, Windows. But not necessarily to embedded
devices, real-time OSes, etc...
- Return handles to I/O resources that the app can feed into its event
loop.
This is much more OS-specific. On Unix/Unix-like OSes this means
returning an array of file descriptors. On Windows it means
returning and array of file handles. This too may not be terribly
portable. And it requires that the application plug the returned
resources into its event loop, and take them out, on every call to
these GSS functions.
There is another model:
> while (1) {
gss_process_events(&minor, ...);
>
> ret = gss_call(&minor, GSS_C_NOWAIT, ...);
> if (ret != 0 && minor == EAGAIN) {
> continue;
> }
> ...
> break;
> }
