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
- GSS-APIv3 sketch Nicolas Williams
- Re: GSS-APIv3 sketch Nicolas Williams
- Re: GSS-APIv3 sketch Nicolas Williams
- Re: GSS-APIv3 sketch Nicolas Williams
- Re: GSS-APIv3 sketch Love Hörnquist Åstrand
- Re: GSS-APIv3 sketch Love Hörnquist Åstrand
- Re: GSS-APIv3 sketch Nicolas Williams
- Re: GSS-APIv3 sketch Jeffrey Hutzelman
- Re: GSS-APIv3 sketch Nicolas Williams
- Re: GSS-APIv3 sketch Nicolas Williams
- Re: GSS-APIv3 sketch Nicolas Williams
- Re: GSS-APIv3 sketch Andrew Bartlett
- Re: GSS-APIv3 sketch Volker Lendecke
- Re: GSS-APIv3 sketch Nicolas Williams
- Re: GSS-APIv3 sketch Nicolas Williams
- Re: GSS-APIv3 sketch Nicolas Williams
- Re: GSS-APIv3 sketch Volker Lendecke
- Re: GSS-APIv3 sketch Stefan (metze) Metzmacher
- Re: GSS-APIv3 sketch Nicolas Williams
- Re: GSS-APIv3 sketch Love Hörnquist Åstrand
- Re: GSS-APIv3 sketch Volker Lendecke
- Re: GSS-APIv3 sketch Nicolas Williams
- Re: GSS-APIv3 sketch Nicolas Williams
- Re: GSS-APIv3 sketch Volker Lendecke
- Re: GSS-APIv3 sketch Volker Lendecke
- Re: GSS-APIv3 sketch Nicolas Williams
- Re: GSS-APIv3 sketch Nicolas Williams
- Re: GSS-APIv3 sketch Volker Lendecke
- Re: GSS-APIv3 sketch Nicolas Williams
- Re: GSS-APIv3 sketch Tom Yu