Rambling Comments

Hosting .Net takes me back to the 'Good ol' days of COM'

2007-07-31T12:15:57Z

It's interesting, no, really, how the more things change the more they stay the same... I've been doing COM for a long time. I first discovered COM back at Interlink when I was writing a windows version of a product call CardMaster which did credit card production. The system supported lots of different machines and each of these machines needed different drivers, the drivers were written in C and usually spoke to the machine via a serial port. In the DOS (actually Concurrent DOS, but...) version of the product I'd used structures of function pointers that the driver populated during an 'open()' call and which were returned to the application so that the application could use this 'opaque' structure to access these machines polymorphically... Think v-tables without the rest of C++...

Moving on to the windows version I knew that I wanted to package each driver in a dll so that we could ship new drivers to users without needing to send them a complete new build of the product... I'd worked through the whole LoadLibrary(), GetProcAddress() malarky and had a rather nice design that provided multiple interfaces to drivers but had two small holes in it; it was hard to manage the lifetime of the dlls so that they stayed loaded for the right amount of time and I had to come up with a couple of interfaces that would represent all drivers forever as it would be a pain to have to change all the drivers if I changed the interfaces.

Just at this point in the development I went to a Microsoft conference. The hot new thing was COM, it seemed very similar to what I'd been designing and solved the dll unload problem with reference counts on the interfaces and the interface evolution problem with dynamic discovery using QueryInterface(). I bought Inside COM, ripped out my custom dll loading system and embraced COM; complete with tear off interfaces and my own COM library that provided the boilerplate implementations for factories and IUnknown, etc. COM was easy then, most, or maybe all of it was in process and marshalling was easy... So easy that often the rules of COM were broken and we developed in process interfaces that could never be marshalled out of process due to data types or design features used...

Time passed. I worked at CSFP which became CSFB and we did a lot of COM. Things were getting more complex, marshalling mattered, most of the time, dodgy designs started to fall away and things were good; well, most of the time, developing OLE-DB providers was definitely not a 'good' period ;). COM contiunued to get gnarly and hairy and more complex and eventually had a + added on the end...

I haven't done much COM recently, but hosting the CLR in The Server Framework requires COM to communicate with it... What I'm finding is that working with the CLR COM interfaces and exposing C++ code to the CLR via COM makes me feel like I'm working back in the, ahem, good ol' days of COM, that is right back at the start before it got all hairy... I'm not quite sure why...

Sometimes it almost seems that they don't want you to get the code to work...

2007-07-24T21:32:15Z

I've spent some time over the last few days playing around with my CLR hosting socket server example. I had stalled on a piece of client work, I've got a bit of a head cold at the moment and my brain just wasn't in the right place for what I was supposed to be doing so I picked up one of more interesting the items on my todo list and took a look at that instead... The bulk of the work flowed nicely but then, just at the end things stopped working for no apparent reason... I'd done what was suggested in the book, the code compiled, the CLR called into my host in the right way and then I got a security policy exception... Hmmm.

I'm looking at having my CLR hosting server control how assemblies are loaded by the CLR. This involves implementing a few COM interfaces (who said .Net killed COM?), mainly IHostAssemblyManager and IHostAssemblyStore. These allow you to jump through some hoops and eventually control how assemblies are loaded... I'd got to the bit where the CLR was finally calling IHostAssemblyStore.ProvideAssembly() on my host and I was checking the binding info and returning an IStream that contained the contents of the assembly file. This is how SQL Server hosts code that lives in the database and it works quite nicely (once you're trained to jump through the required hoops without asking too many questions).

So, I was returning a valid IStream which contained the correct assembly but my code still didn't run and I was getting security policy exceptions. I double checked my reference book, "Customizing the Microsoft.NET Framework Common Language Runtime" by Steven Pratschner, and I seemed to be doing everything that I needed to be doing... I did a Google search and someone else had been having a similar problem and his final comment was that the book did mention the issue that he had but he hadn't noticed it... I checked things out and finally found the problem mentioned in a different chapter, some way further on from the actual code that dealt with assembly store customisation... It seems that if you provide your own assembly store then you also have to provide a managed HostSecurityManager which adds some "evidence" onto the assembly that you've loaded so that the CAS stuff works properly... The chapter where this is explained goes on to show how to create custom evidence and all kinds of clever things that I have no interest in and then, right at the end, subtly includes a comment about how the security manager implementation needs to add more evidence (in addition to all the custom stuff that the rest of the chapter had been dealing with). If this additional evidence isn't added then the new custom evidence wont work... The good thing is, for me at least, just adding the standard evidence works well enough for now. The loaded assemblies will have full trust but that's fine for my example.

So, the minimal managed security manager implementation that you need to get your custom assembly store working is something like this:

   public class SecurityManager : HostSecurityManager
   {
      public override HostSecurityManagerOptions Flags
      {
         get
         {
            return (HostSecurityManagerOptions.HostAssemblyEvidence | 
               HostSecurityManagerOptions.HostPolicyLevel);
         }
      }

      public override Evidence ProvideAssemblyEvidence(
         Assembly loadedAssembly, 
         Evidence inputEvidence)
      {
         if (loadedAssembly.HostContext == 42)
         {
            inputEvidence.AddHost(new Zone(SecurityZone.MyComputer));
         }

         return inputEvidence;
      }
   }

And now that I've worked around the fact that you can't reuse the IStream that you give out in one call to IHostAssemblyStore.ProvideAssembly() in another call (probably due to the cursor in the stream being wrong), everything seems to be working nicely.

Echoes from the CLR

2007-03-20T12:51:41Z

The work on the CLR hosting socket server example is going pretty well. I now have a server that can pass server notifications to managed code that either runs in an AppDomain per connection or within a single AppDomain (depending on how isolated you want the user code to be). I think I'm pretty much there as far as what I want to demonstrate is concerned; it works and the line between managed and unmanaged code is likely to vary depending on a client's particular requirements so there's little point in extending the example code any further. Hopefully I'll get a chance to clean things up a little more and then do some performance comparisons between a pure unmanaged server, a pure managed server and a hybrid...

Socket Server that hosts the CLR

2007-03-15T17:49:10Z

My investigations into CLR hosting are going well and today I built an echo sever based on The Server Framework and my CLR Hosting helper library. The idea is that the server can deal with the network IO and then hand off the 'real work' to some .Net code. So far the integration is going pretty smoothly....

Yay .Net sockets stuff...

2007-03-05T04:35:35Z

Nice to see that the new beta, sorry, CTP, of the next .Net Framework will increase the performance of .Net sockets by 70%! Way to go .Net dudes....

Interesting to see that it's a joint effort between the System.Net people (who, I assume own the sockets code) and the CLR people (who own the platform)... I wonder what the CLR guys brought to the tuning table...

It would be nice to know how the new (and existing) .Net sockets performance compares with the Win32 equivalent...

Hmm, is this really a good fix?

2007-03-05T04:30:38Z

Back in July Joe Duffy wrote an interesting piece on the CLR thread pool. I commented on it then, here. He's now written another piece about why they increased the maximum number of threads in "the thread pool" from 25/cpu to 250/cpu. Joe, I refer you to my previous comment... You're solving the wrong problem!

Dino Viehland on CLR hosting

2007-02-13T12:13:08Z

This is mainly a reminder for me so that I can read this when I get back from Jackson Hole...

Dino Viehland has written some interesting looking blog posts on how to implement the thread/task and syncrhonisation host managers for a hosted CLR. Note that this is all "Whidbey beta 1" stuff so, well, your milage may vary...

Lifetime management issues with CLR hosting

2007-02-12T16:41:03Z

I'm still playing with hosting the CLR in C++ (using "Customizing the Microsoft.NET Framework Common Language Runtime" by Steven Pratschner as my guide)... It's an interesting journey but, once again, I wonder who makes the important technical decisions at Microsoft and how they sleep at night ;) .

I'm currently playing with the ICLRRuntimeHost interface. This lets you load the CLR into your unmanaged process and gives you a remarkable amount of control over how the CLR that you're hosting operates. Unfortunately it's got some dubious design issues... Firstly you can only have one instance of the CLR hosted in your process; that's just about fair enough, I guess, but I'd still be curious to know why... Secondly, if you try and load a second or subsequent instance you'll get S_FALSE returned from your call to CorBindToRuntimeEx()... The error isn't currently documented in the online docs for the function... Interestingly, you get the same error whether you've requested the same version of the CLR with the same configuration settings or if you've requested a completely different version, so, it doesn't mean "you've already loaded the CLR like this" it means "you've already loaded a version of the CLR somehow". Again this isn't likely to be much of a problem as you can't ever unload the CLR so the first one that you load is the only one you can ever load...

Then there's the Stop() method on ICLRRuntimeHost... The docs for this are "interesting"; online we have "pre-release" docs which say: "This method does not release resources to the host, unload application domains, or destroy threads. You must terminate the process to release these resources.", whilst VS 2005 SP1's help says "Do not call this method. The host cannot unload the runtime from a process." which is amusing at best. What's more, if you DO call it then it seems to return E_UNEXPECTED if you call it before starting the CLR (which is probably what you'd expect) and it seems to work like a 'reference counted' "Stop" (you can call it as many times as you've called Start() and all except the last call returns S_FALSE and the last call returns S_OK), which, again, is pretty much what you might expect... Unfortunately, once it's returned S_OK the CLR in your process is screwed, not only is it stopped (probably not that cleanly if the docs are anything to go by) but you can't ever start another CLR in your process; though calling CorBindToRuntimeEx() still returns S_FALSE...

Of course none of this is really a "problem" if you use the code in the way that some of the docs that you might come across suggest that you should do but I do find myself wondering "Why was v2.0 of the .Net Common Language Runtime allowed to go out the door with this half arsed implementation of a new interface?" After all, if you use the 'backwards compatibility' excuse then, well, even if you were relying on using the functionality during the beta phase, you shouldn't be calling Stop() anymore so surely it's better to break any code that was using it rather than leaving it "working"? Or, if you really couldn't change the interface at that late a date then surely a method that's documented as "don't call this" should be a no-op inside and just return S_OK or S_FALSE the whole time and do nothing?

I'm also a bit concerned about the fact that you can't shut the CLR down cleanly once it's started... I'm a bit of a fan of being able to start and stop my code, no matter how complex it is. The fact that it looks like the original design allowed for stopping the CLR and the actual implementation can't do that is a little worrying...

Of course this annoys me most simply because it makes testing any code that happens to host the CLR a much harder job. As is often the way, the implementation flaw in Microsoft's code leaks out and becomes a flaw in all the code that uses it... I can't test my code to load and host the CLR with various different, valid and invalid, options without starting a different process for each test... Bleugh...

I think I need a new category of blog postings, "Rants", though perhaps most of my postings could be categorised that way...

Crapness in mscoree.h

2007-02-08T15:49:33Z

I'm playing around with hosting the CLR in C++ at present and have come across a bit of crapness in the mscoree.h file...

#if (_MSC_VER < 1300 || _WIN32_WINNT < 0x0500)
typedef VOID ( __stdcall *WAITORTIMERCALLBACK )(
    PVOID __MIDL_0011,
    BOOL __MIDL_0012);

#endif // (_MSC_VER < 1300 || _WIN32_WINNT < 0x0500)

This effectively says, if you're using VC6 or you're compiling for less than v5 of Windows NT then you don't have this typedef so here it is... Unfortunately, if you're compiling with VC6 but you're using the platform SDK then you already have that typedef in winbase.h and, well, mscoree.h wont compile...

It's a pity that versions of the Platform SDK aren't identifiable by a #define as this would make it easy to solve this kind of problem (and lots of others!) in a neat and maintainable way, but...

So far the best I've come up with is to wrap the inclusion of the real mscoree.h in my own include and check for use of VC6 and lie about the compilers age to mscoree.h... Anyone got any better suggestions?

CLR thread pool woes

2006-07-12T07:47:38Z

Joe Duffy has written an interesting piece over on "Generalities & Details: Adventures in the High-tech Underbelly" about problems with the CLR thread pool. Joe's a program manager on the CLR team at Microsoft, so he knows what he's talking about!

I find the issues that Joe raises interesting as I spent some time designing a flexible thread pool for my C++ IOCP servers some time go and came across the problems that he's facing. In essence the problem is that you want to allow the thread pool to grow and shrink based on demand but you don't want it to grow too fast as threads are expensive things to create and creating too many hurts performance, yet you don't want it to grow too slowly as that hurts throughput of work items; especially if the work items are performing blocking operations.

Please bear in mind that I haven't used the CLR thread pool a great deal because most of my clients still require that I write in C++, so I may have things wrong, be gentle with me...

It sounds like Joe's CLR thread pool design is similar to my first cut of a design. There are a minimum number of threads that the pool will hold and a throttling time that restricts creating new threads for a period after a thread has been created. The idea being that as work comes in you allocate each work item to a thread until all threads are busy and then you may decide to start a new thread, or you may decide to wait a while (because you just started a new thread). If threads are idle for too long then they are removed from the pool and the pool shrinks. If the work items arrive at a "reasonable" and consistent speed and the work items take a "reasonable" amount of time then you're fine. The pool will expand and contract as required and work will be done in a "reasonable" time. The problem is what happens when the work items occur in batches with gaps between and some or all of the work items take a long period of time on blocking operations (like database access, for example).

My final design was a little more complex than Joe's design (possibly too complex!). I have an initial count of threads, which is the number that the thread pool creates when it starts. I have a minimum number of threads, which is the number below which the thread pool will not shrink. I have a maximum number of threads, which is the number above which the thread pool will not grow. There are also a maximum number of 'dormant' threads, which is the number of threads that aren't currently processing work items; once this limit is exceeded we start shutting some threads down. Then there are the dispatch timeout values. I have two; one for when the thread pool is not currently running at maximum threads, this is the timeout that determines how long to wait between starting new threads. The second is a timeout that is used when the pool is running at maximum threads, this timeout simply slows the dispatch monitoring loop so that we don't busy wait when we aren't allowed to increase the capacity of the pool. The final configuration parameter to the thread pool is the pool maintenance period; this determines how often the pool considers shrinking itself. There's a detailed, if old, design rationale in this CodeProject article here.

In itself my design simply moves the problem around a little, however there are two advantages that I have when using my thread pool in a process: Firstly, I can tune the thread pool to suit the application; all of the configuration parameters are passed in to the constructor, they can be sourced from an external config system if required and thus can be adjusted on a per process level as you profile the process that's using them. Secondly, I can have more than one thread pool in a process; there is no need for a single process wide thread pool that has to be appropriate for all of the async work within a process.

I can understand how the concept of "THE CLR Thread pool" might have come about. It's convenient for programmers using various APIs if they don't have to worry about providing a thread pool and that the API just goes off an "grabs" THE thread pool. Unfortunately, singletons are evil ;) and tempting as it may be to make it "easier" for people by hiding things and allowing access to global variables (the single thread pool object!) it's rarely appropriate. The problem is that for this design to work, the CLR team has to anticipate all possible usage patterns and optimise for all of them... Obviously needing to have multiple thread pools is unusual, but it may happen, it may be that there are some work items that are slow and should not take up all of your single thread pool's resources and some that are fast and must be processed reasonably quickly... If you, the programmer, can decide to use two, or more, appropriately tuned thread pools then tuning one pool to be just right for a mixed set of work item requirements is no longer an issue... After all, no matter how large a number of threads, N, you allow in your single pool you only need N+1 of your slow work items to prevent your faster work items from being processed at a "reasonable" rate. With two, or more, pools this is never an issue...

So, my advice to Joe is this: Firstly, allow the user access to all of the tuning parameters that the pool supports, not just the number of threads, but also any timeouts, etc. Default to "sensible" values, write MSDN articles on why you shouldn't use "foolish" values and then trust the user to do the right thing. Second, for shipping products that use the thread pool allow the user to configure the thread pool via an external source, such as a config file. Thirdly, consider adjusting all of the APIs that currently use THE thread pool to also be callable with A thread pool and then allow the user to create and configure additional pools within their process.

Now I'm confused (C++/CLI destructors)

2006-01-08T13:36:48Z

So here I am, writing a piece about how the C++/CLI destructor and finalizer stuff could have been a bit neater and I put together some sample code to demonstrate my point and it doesn't do what the docs I mentioned yesterday suggest that it should do...

Given this example class....

ref class Example
{
   public :
   
      Example(
         bool throws)
         : m_count(s_count++),
            m_string(gcnew String("MyString"))
      {
         Console::WriteLine(m_count + " - Example(throws = " + throws + ")");

         if (throws)
         {
            throw "Thrown";
         }
      }
   
      Example()
         : m_count(s_count++),
            m_string(gcnew String("MyString"))
      {
         Console::WriteLine(m_count + " - Example");
      }
   
      ~Example()
      {
         Console::WriteLine(m_count + " - ~Example");

         delete m_string;
	
         this->!Example();            
      }

      !Example()
      {
         Console::WriteLine(m_count + " - !Example");
      }

   private :

      const int m_count;

      String ^m_string;

      static int s_count = 0;
};

And the following test code...

int main(array<System::String> ^args)
{
   try
   {
      Example example(true);
   }
   catch(...)
   {
      Console::WriteLine("Caught");
   }
   
   try
   {
      Example ^example = gcnew Example(true);
   }
   catch(...)
   {
      Console::WriteLine("Caught");
   }
    
   return 0;
}

I was expecting, based on these docs from MSDN, that the output would be something like this:

0 - Example
0 - ~Example
0 - !Example
Caught
1 - Example
Caught
1 - !Example

But, instead, I actually get this:

0 - Example
Caught
1 - Example
Caught
1 - !Example
0 - !Example

That is, the destructor for the stack based object isn't called (as the docs seem to imply it would be), but the finalizers are when the objects are garbage collected...

Am I being dense here?

Why are the "event" classes in .Net STILL broken?

2005-11-15T18:01:45Z

Whilst I'm ranting about the little things...

You still can't create named versions of the .Net ManualResetEvent and AutoResetEvent, even in .Net 2.0. Wasn't everything going to be fixed in Whidbey?

Of course, I realise that you can "simply" access the underlying Win32 API to do it, but a) why should we have to? and b) it's not recommended that you do...

I guess the fact that the P/Invoke route isn't recommended is the reason for the dearth of nicely packaged up solutions to this problem; surely anyone who needs this functionality would write an object that wraps it up nicely rather than doing it "long hand" like this? I particularly like the way that example uses the hole in the encapsulation of ManualResetEvent to replace the event handle so that he can use WaitOne() on it...

New C# v3 features explained in context

2005-09-22T08:02:53Z

Ted Neward has a very nice piece about the new language features in C# v3 and how they work together to provide something quite powerful. Go read it!

Given that implicit typing, object initialisers and extension methods are all designed to allow LINQ to be a be able to generate classes on the fly and extend existing classes I'd still be happier if they could be optionally restricted from use on 'normal' classes to help prevent the less experienced running amok with these new language features and creating code that has interesting maintenance properties...

Restricting the use of extension methods?

2005-09-19T10:37:56Z

Having looked through the slides that Vagn pointed me to in a comment to my recent post about C# v3.0 Extension Methods I can understand, a little more, about the reasoning behind the change to the language. Given that the C# v3.0 spec contains the following warning:

"Extension methods are less discoverable and more limited in functionality than instance methods. For those reasons, it is recommended that extension methods be used sparingly and only in situations where instance methods are not feasible or possible. Extension members of other kinds, such as properties, events, and operators, are being considered but are currently not supported."

Perhaps it would be a good idea to make classes have to 'opt in' to enable extension methods on them. A keyword, such as extensible or whatever could be added to a class to allow the use of extension methods on it, much in the same way that sealed can be used to prevent extension via inheritance. This would reduce the likelyhood that the feature will be missused by inexperienced programmers and would mean that classes could be 'closed for extension' by design. I would expect much of the .Net framework would naturally be 'closed', in the same way that much of it is 'sealed'. This wouldn't prevent the use of the feature where it was needed but might restrict the confusion that could be caused if it were overused.

Thoughts?

C# v3 Extension methods, syntactic sugar for the lack of free functions?

2005-09-16T14:12:36Z

There's a lot of noise coming out of the Microsoft PDC right now. Something that interested me was the future direction of C#; you can grab the spec from here.

It seems they're adding "extension methods" which, to me, appear to be just syntactic sugar to make up for the lack of free functions...

In C++ you can have functions that aren't part of an object. In C no functions are part of an object. These are "free" functions. You can't have these kind of things in C# and Java because everything has to be part of an object even if the only purpose for the object's existence is to provide a home for a collection of static methods, go figure...

In C++ a recent idiom is to prefer free functions over object methods where possible. The argument is that creating non-member, non-friend, functions increases encapsulation because these functions don't need access to the object internals and therefore bundling them with the object simply reduces the encapsulation that the object provides by expanding the amount of code that has unnecessary access to the object's internals.

This means that, in modern C++, you may often see things like this:

int ToInt32(const std::string &stringRep);

which can be used like this:

const int i = ToInt32(customerNumber);

Up until now the nearest that you could get to this in C# was something like this:

public class Stuff
{
  public static int ToInt32(string stringRep);
}

which can be used like this:

int i = Stuff::ToInt32(customerNumber);

The new "extension methods" proposal means that the call above can be rendered as this:

int i = customerNumber.ToInt32();

Which, in my mind, is madness. The method is not a member of the object so why should you call it using member syntax? What value does it add to be able to do this? If you're looking to remove the crufty Stuff:: from the front of the call then why not simply allow functions to be defined at namespace scope? Then you could bring the names in with a normal using statement and use them in a way that's expected:

int i = ToInt32(customerNumber);

It's quite clear that ToInt32 comes from a namespace somewhere and isn't a member of the object in question...

So, my question to all you .Net people is why is this new syntax a good thing? I can only see scope for confusion and the eventual banning of this kind of thing in local coding standards...