Re: GSS-APIv3 sketch

Nicolas Williams <Nicolas.Williams@sun.com> Wed, 11 November 2009 23:19 UTC

Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C247C3A696C for <kitten@core3.amsl.com>; Wed, 11 Nov 2009 15:19:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.027
X-Spam-Level:
X-Spam-Status: No, score=-6.027 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9R8Qi+9nDTb for <kitten@core3.amsl.com>; Wed, 11 Nov 2009 15:19:23 -0800 (PST)
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 098403A67F1 for <kitten@ietf.org>; Wed, 11 Nov 2009 15:19:23 -0800 (PST)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nABNJnIM018385 for <kitten@ietf.org>; Wed, 11 Nov 2009 23:19:49 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nABNJnWk064801 for <kitten@ietf.org>; Wed, 11 Nov 2009 16:19:49 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nABN0kWM014516; Wed, 11 Nov 2009 17:00:46 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nABN0jR7014515; Wed, 11 Nov 2009 17:00:45 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Wed, 11 Nov 2009 17:00:45 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Andrew Bartlett <abartlet@samba.org>
Subject: Re: GSS-APIv3 sketch
Message-ID: <20091111230044.GW1105@Sun.COM>
References: <20091111181140.GC10501@Sun.COM> <C111F570-A844-4782-B561-08B6685D7E09@apple.com> <20091111184244.GN1105@Sun.COM> <20091111184726.GD10501@Sun.COM> <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net>
User-Agent: Mutt/1.5.7i
Cc: "kitten@ietf.org" <kitten@ietf.org>, vl <vl@samba.org>, Love Hörnquist Åstrand <lha@apple.com>
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Nov 2009 23:19:23 -0000

On Thu, Nov 12, 2009 at 09:59:26AM +1100, Andrew Bartlett wrote:
> I'm hoping that Volker or Metze (CC'ed async experts on the Samba Team)
> can fill out some more detail, but I'll start by nothing that anything
> that requires threads, or causes the library to start threads is a
> non-starter for Samba.  
> 
> Creating threads behind the applications' back is a really bad idea. 

In the Solaris unified process model this can just happen.  That is,
libraries are free to create worker threads.

> We really need a proper state machine, with integration available into
> our event library (or any other the event library the caller
> provides).  

That's much more work, and much less portable, and much more OS-/event-
API-specific.  I'm speaking here from a standardization point of view.
(In fact, using libevent would result in reasonably portable interfaces,
certainly across all Unix, Linux, and BSD type operating systems.  But
that's beside the point that I'm making.)

I think implementations could certainly have such interfaces, but I
think we'd not standardize them here.

Nico
--