Re: KITTEN: IETF 75 - 76

[Nicolas Williams <Nicolas.Williams at sun.com>]

On Wed, Sep 02, 2009 at 09:12:00PM -0400, Michael B Allen wrote:
> On Wed, 2 Sep 2009 16:26:52 -0500
> Nicolas Williams <Nicolas.Williams at sun.com> wrote:
> > The problem with this model is that it has the GSS-API impose its own
> > event loop on the application.  Imagine if every library did that!  An
> > application that uses multiple such libraries, where some such libraries
> > use other such libraries, would be very difficult to get to work at all,
> > particularly without threading or sub-processes.
> > 
> > I don't understand your aversion to callbacks.  Callbacks are
> > exceedingly common in C APIs nowadays, and that's a good thing, IMO.
> 
> I think you're exaggerating, if not misrepresenting, the detractions
> of the NOWAIT flag technique. But it is no matter. For a variety of
> reasons I will not pursue the issue further.

I have worked on applications that use over half a dozen layered
components, at least two of which need to do blocking I/O operations,
plus the application itself being async I/O event driven.

Putting together such an application with your async I/O model would
result in an enormous amount of complication.

I'd much rather have the library give me either file descriptors to
select on, or a callback.

> However, before I go back to lurking, I have to declare that callbacks
> are NOT simple. They can be quite complicated. Just from looking at
> function signatures posted in this thread I personally have no idea
> how these callbacks would actually work. Are they called by another
> thread, by a signal, through another call or by another caller? Is
> locking required? What data is safe to modify in the callback? They
> seem C oriented - do the semantics change if a different language is
> used like Java? Hopefully the answers to these questions will be clear
> if these callbacks do end up in a GSSAPI implementations.

Callbacks are simple (and the ones I proposed certainly are).  One
should specify the calling context, as you point out.  To be most
portable we should say that callback functions must be async-signal-
safe, which means that callback functions should limit themselves to:
signalling condition variables, writing to a pipe, or otherwise posting
an event to another event loop.

Nico
--