Everhart,Glenn
From:	Zygmunt Wiercioch [ZWiercio@JetForm.com]
Sent:	Friday, March 13, 1998 10:54 AM
To:	'ntdev@atria.com'
Subject:	RE: [ntdev] RE: designing software under NT
> From: Paul Bunn [mailto:Paul@ULTRABAC.com]
> My point is that it pays to remember the Microsoft saying "threads are
> cheap *not* free".  Don't go wild with threads -- you'll end up with a
> very inefficient design that will not scale.  The best example of this
> type of bad design is the creation of a new thread for a new client
> connection in a client/server type application.  This type of design
> will scale great to 10, 50 or 100 users but will hit this brick wall
> where performance will just deteriorate rapidly and the system will
> grind to a halt.  The solution is completion ports.  These are
> effectively the "Daytona" engine -- the main reason why NT3.50 was
> faster than 3.51.  What you have with CPs is a number of worker threads
> that are scheduled in a last-in/first-out fashion that effectively
> eliminates context switching within the application.  Typically you
> create a worker thread for each processor that you have in the system,
> note that "worker thread" is just a name to describe a thread that looks
> at a queue of work to do.  CPs are associated with overlapped-I/O and
> are not available on the rotting dogmess aka("Win95").  Worker threads
> wait on the CP which then gets state information on a piece of work to
> be done, it is carried out and usually another I/O initiated to keep the
> CP pipe full.  When it completes the work it waits on the CP again, and
> if more work is available it is given it immediately, with *no* context
> switch at all.

Paul,
This is a very good and useful explanation, and the SDK has a number of
examples of using I/O completion ports to allow a single thread to
handle multiple I/O requests and reduce the number of context switches.
The problem is, is it possible to use the I/O completion port method and
ImpersonateNamedPipeClient ?  

I don't see an easy way of doing it, since the single thread is handling
multiple simultaneous client connections. I suppose that depending on
the work the server is doing, it could do an impersonate on the first
read from a client and do any setup work in the context of that client.
It would then revert to self for the duration of handling that
connection, with possibly doing another impersonate at the end, when
closing the connection and doing any cleanup.  Is this a viable option
or is the thread/connection the way to go in that scenario ?

Zygmunt Wiercioch
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[ To unsubscribe, send email to ntdev-request@atria.com with body
UNSUBSCRIBE (the subject is ignored). ]