Re: GSS-APIv3 sketch

Volker Lendecke <Volker.Lendecke@SerNet.DE> Thu, 12 November 2009 18:54 UTC

Return-Path: <Volker.Lendecke@SerNet.DE>
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 4DE2F3A6B17 for <kitten@core3.amsl.com>; Thu, 12 Nov 2009 10:54:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 xsLVKqo2CSge for <kitten@core3.amsl.com>; Thu, 12 Nov 2009 10:54:30 -0800 (PST)
Received: from mail.SerNet.de (mail1.SerNet.de [193.175.80.2]) by core3.amsl.com (Postfix) with ESMTP id 2D3563A683A for <kitten@ietf.org>; Thu, 12 Nov 2009 10:54:30 -0800 (PST)
Received: from intern.SerNet.DE by mail.SerNet.DE with esmtp (Exim 4.63 #1) id 1N8eoq-0007pG-TN; Thu, 12 Nov 2009 19:54:56 +0100
Received: by intern.SerNet.DE id 1N8eoq-006pRQ-LY; Thu, 12 Nov 2009 19:54:56 +0100
Received: by intern.SerNet.DE id 1N8eoq-006pR9-HF; Thu, 12 Nov 2009 19:54:56 +0100
Date: Thu, 12 Nov 2009 19:54:56 +0100
From: Volker Lendecke <Volker.Lendecke@SerNet.DE>
To: Nicolas Williams <Nicolas.Williams@sun.com>
Subject: Re: GSS-APIv3 sketch
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> <E1N8MHF-004jYm-T7@intern.SerNet.DE> <20091111230442.GY1105@Sun.COM> <E1N8Twh-0057MW-SY@intern.SerNet.DE> <20091112170403.GB1105@Sun.COM>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY"
Content-Disposition: inline
In-Reply-To: <20091112170403.GB1105@Sun.COM>
User-Agent: Mutt/1.5.9i
Message-Id: <E1N8eoq-006pRQ-LY@intern.SerNet.DE>
Organization: SerNet GmbH, Goettingen, Germany
Cc: "kitten@ietf.org" <kitten@ietf.org>, Love Hörnquist Åstrand <lha@apple.com>
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Volker.Lendecke@SerNet.DE
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: Thu, 12 Nov 2009 18:54:31 -0000

On Thu, Nov 12, 2009 at 11:04:03AM -0600, Nicolas Williams wrote:
> I'd love to see that, please :)

It was a talk at the OpenSolaris developer conference in
Dresden a couple of weeks ago:

http://www.osdevcon.org/2009/program_detail.html#zdenek

> OpenSolaris' fork() == fork1(), and it has forkx(2) for libraries.
> forkx(2) allows library-forked child procs to not interfere with the
> application running in the parent, e.g., by not triggering SIGCHLD and
> not showing up in plain wait(3C) calls.  And libraries in OpenSolaris
> that create worker threads take care to use pthread_atfork() and
> atexit() handlers to do fork/exit cleanup.
> 
> Of course, pthread_atfork() and atexit() are standard functions...
> Libraries on Linux should use them too.

Yes, sure. It is all possible and doable. But I am just
scared by its complexity. Race conditions and deadlocks can
stay undetected for very long and if they happen they can
turn out to be very hard to reproduce and fix. But that
might be just me. I know event-based programming has its own
quirks and complexities, but at least you can the programs
under a debugger.

> If there are issues in OpenSolaris (apologies to the list) about this, I
> really want to hear about them, because we need to make sure they are
> addressed if it's at all possible.  I also care to hear about issues on
> Linux and *BSD though (I do some development on Linux, but mostly I want
> to be informed).

There were no special Solaris issues mentioned. All standard
pthreads stuff. The author (interestingly a SUN employee)
talked about Solaris crypto libraries having issues, but he
mostly used them as examples from his own experience fixing
threaded libs. The problems he mentioned however were pretty
generic.

Let me point out another thing: By using threads and a
purely blocking API, you force everyone into threads. If you
do it async, it is very easy to create blocking wrappers
around the async calls which then can be used in threaded
programs. The other way round is a lot harder.

Volker