http://blogs.msdn.com/earhart/archive/2005/01/19/356109.aspxSo I've checked in the new Longhorn threadpool. (Unmanaged). If you use the threadpool, I think you'll enjoy it; there are a number of API features which should make it very easy to write correct code which uses it, particularly in the area of cleanupen-USCommunityServer 2.1 SP1 (Build: 61025.2)http://blogs.msdn.com/earhart/archive/2005/01/19/356109.aspx#359370Mon, 24 Jan 2005 12:12:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:359370Pavel LebedinskyAre the docs for the new threadpool publicly available? <br> <br>Good luck fixing the loader lock mess. The current design is (in my opinion) just asking for problems: <br> <br>1. Create a set of rules that forbid doing most non-trivial things in code that runs inside the loader lock. <br> <br>2. Expose a very easy way for people to write such code without even realizing it (static C++ constructors/destructors). <br> <br>3. Provide no mechanism to enforce the rules. <br> <br>4. Make sure that even when the rules are violated, things still seem to work correctly 99% of the time. <br> <br>5. Watch people fall into the same trap over and over again. <br> <br>Really, how are people supposed to find out that (for example) declaring a global CComBSTR object is a big no-no, when it works just fine in the vast majority of cases?http://blogs.msdn.com/earhart/archive/2005/01/19/356109.aspx#372909Tue, 15 Feb 2005 14:11:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:372909Ramanujamwow that's great..........to hear... <br>even we are working on kernel 32....in our IBM labs