Re: GSS-APIv3 sketch

[Volker Lendecke <[e-mail]>]

On Thu, Nov 12, 2009 at 02:10:15PM -0600, Nicolas Williams wrote:
> On Thu, Nov 12, 2009 at 09:06:01PM +0100, Volker Lendecke wrote:
> > On Thu, Nov 12, 2009 at 01:42:51PM -0600, Nicolas Williams wrote:
> > > On Thu, Nov 12, 2009 at 07:54:56PM +0100, Volker Lendecke wrote:
> > > > 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.
> > > 
> > > That ship has sailed: Solaris 10 and up has a unified process model, and
> > > it's a threaded process model.
> > 
> > So GSSAPI is a Solaris only thing?
> 
> How does that follow?  I'm advising you that on Solaris you can expect
> core libraries to launch threads, and you can expect them to use
> pthread_atfork() and atexit() propoerly.
> 
> Note that I'm NOT saying "you can't have a libevent-/whatever-based GSS
> async extension".  I'm not being hostile to what you propose nor to you.
> 
> I'm saying that I think we must have a callback-based GSS async
> extension as _one_ choice, and probably the required-to-implement choice
> because that one makes the fewest assumptions about operating systems.

That sounds good! I had understood that you only want the
blocking API, depending on threads.

Thanks :-)

Volker