Re: KITTEN: IETF 75 - 76

[Michael B Allen <[e-mail]>]

On Wed, 2 Sep 2009 16:26:52 -0500
Nicolas Williams <[e-mail]> wrote:

> On Wed, Sep 02, 2009 at 05:20:15PM -0400, Michael B Allen wrote:
> > There is another model:
> > 
> > > > while (1) {
> >         gss_process_events(&minor, ...);
> > > > ...
> 
> 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.

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.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/