Thank you - and now to the question: How can the CLR support dynamically typed languages like Common Lisp, Dylan, ... ?

Hi Chris, I was wondering why the .NET framework does not support multiple inheritance like in the case of c++ ? Multiple inheritance of interfaces is allowed but the similar situation with classes doesn't seem to work. Why is this ? I have in many situations wanted to inherit from multiple classes but then could not with the restrictions in the framework. I end up changing the object model to accomodate such a requirement and generally find a workaround to do the same when i could have done it much easier and efficiently with multiple inheritance. Well i know that multiple inheritance is not allowed because of the drawbacks of the same in c++. Like two parent classes having a same function and if user tries to call the base class method then there would be a confusion in the compiler as to which method is to be called. But in the .NET framework since every field, property and method is strongly typed with the classes, design could have been made to include this functionality and solve the problem that existed in c++. That is the case wrt to inheriting multiple interfaces right ? Am i right in the previous statement or am i missing something major here ? It would be of great help to me and to many others to understand the motive of such a design decision in the framework. Thanks in advance for any information you can provide in this area ! Reference : Your article on Interface layout cleared out lots of things and was very helpful. http://blogs.gotdotnet.com/cbrumme/permalink.aspx/2fad6a65-3ced-49b4-ae8b-c4068bad25fc

Chris, thanks for keeping your blog, it is awesome. I would like see discussion on CLR memory model/thread safety. Thing like are Interlocked. Increment (which according to docs is only guaranteed to be atomic). Also would be helpful discussion of performance of things like cast, etc.

Chris, Can you tell us a bit more about remoting, and how it works with async delegate calls? WebServices provides a way to write async server calls, BeginXXX, EndXXX, and that in turn allows the calling thread (from IIS) to return to the thread pool and process more requests (I presume). Part of me is not sure this belongs on the Remoting side of things, however it just seems like a 'good idea'. From your past posts, I see this works for the client, when using async delegates and remoting. What are the technical design reasons for not providing the server side of the story? Anyhow, Chris

hi chris 1. can u elaborate more about com+ and .net , how much interop is going on there , is using IDispach when unmanaged calls managed code. 2. Debugging and interop , when a compiled manged application is compiled with PDB , how much interop is used behind the scene in order to investigate the pdb file. tnx in advance , your blog is great yosi

Hi Chris I would be very interested in the metadata peculiarities of multi-module assemblies. Which metadata tables belong to the assembly's manifest and are those tables only found in the primary module? Particularly, I find the ECMA specification of AssemblyRefs confusing, because it requires that "the manifest for the executing assembly contain a declaration for any assembly referenced by the executing code" (Part II, 6.3). From this, I conclude that AssemblyRefs are included in the primary module (which contains the assembly's manifest). Still, these tokens are needed for the TypeRefs to these other assemblies, and the specification also says that the ExportedType table is the only table containing tokens from other modules, so how does that work? Or am I mistaken, and the whole manifest story isn't constrained to the primary module; i.e. every module (also auxiliary ones) may contain AssemblyRef, File, ManifestResource, and ExportedType tables? But then this doesn't fit to the rule that all files of an assembly must be defined in the primary module. Maybe you could explain this a litte. Fabian

Chris: This is awesome. I have no topic requests but would just like the blog to keep going! I've learned more in one day of reading than I have in the past 6 months of working w/ the .NET Framework!! Thanks again, Craig

hi Chris, i'd like to be able to inject interception code when calling into objects without the overhead imposed on ContextBoundObject's IMessageSinks (building the IMessage my require boxings etc). I'm intersted in being able to provide Pre/Post processing: 1) disregarding the actuall method arguments and 2) If i need to know the parameters i would like to use reflection on the intercepted method and be able to look at the current stack for the values themselves. The only solution i found for this problem currently is using CodeDOM to generate interception on the fly, implementing the necessary interfaces. thx, cobby. p.s: from what i've read so far, you should definitely consider moving your [more technical] blog stuff to some less esoteric places (how about a "CLR internals" book?)

Hi Chris, I wanted to thank you for your blog - easily one of the best and most informative I've seen. A question you might be able to shed some light on for me has to do with raising a ThreadAbort exception and terminating threads. Are Aborts raised in a synchronous manner so that it must be in a wait state (alertable or otherwise) or can it interrupt running code? For example, if the code were in a tight for-loop, could another thread issue an abort and actually interrupt the other thread? (side question: If it can actually interrupt it what mechanism is used to inject/raise the abort in the execution stream?) Also, you mentioned that TerminateThread should never be used. I agree in general, but how then does one handle the case of stopping a runaway thread? (This ties back to the other question about when an abort is seen). The scenario I have in mind is of a control engine executing user-defined code that is less-trusted then the execution engine - if the code is malicious or poorly written it would be desirable to be able to shut it down. Thanks, Dave

Dave, (are you the David Levine I worked with at Borland & Oracle?) If you abort your own thread via something like Thread.CurrentThread.Abort(), then the exception is raised synchronously. If you abort another thread, it is raised asynchronously. If that thread is in a managed blocking operation, we break it out of the wait state. If it is executing unmanaged code, we must wait for it to return to managed code before we can safely take control of it. But if it is executing managed code, we will take control of it under any circumstances. Even if the thread is executing "while (true) continue;" which is JITted to a single machine instruction like "label: JMP label" we can take control. Conceptually, this is like taking control of the thread so that a garbage collection can proceed. In fact, our current mechanism is slightly different from this. On X86, we can take control for a ThreadAbort on any JITted machine instruction except (I think) the prolog or epilog of a method. In the future, we're likely to change the precise rules so that we can get more commonality with garbage collection and so that we can enable more compiler optimizations in the presence of exceptions. So you can use Thread.Abort to take control of a runaway thread in managed code. If you granted a thread UnmanagedCodePermission or a similar permission, it better not be runaway. You cannot safely take control of a thread that is executing unmanaged code on the Windows operating system -- unless you are willing to terminate the process.

Vijay, There are a number of reasons we don't implement Multiple Implementation Inheritance directly. (As you know, we support Multiple Interface Inheritance). However, I should point out that it's possible for compilers to create MI for their types inside the CLR. There are a few rough edges if you go down this path: the result is unverifiable, there is no interop with other languages via the CLS, and in V1 and V1.1 you may run into deadlocks with the OS loader lock. (We're fixing that last problem, but the first two problems remain). The technique is to generate some VTables in RVA-based static fields. In order to deposit the addresses of managed methods (which probably haven't been JITted yet), you use the VTFixup construct. This construct is a table of triplets. The triplets consist of a token to a managed method, an address in your image that should be fixed up (in this case, a slot of the VTable you are creating in the RVA-based static), and some flags. The possible flags are described in corhdr.h and they allow you to specify 32- vs. 64-bit pointer sizes, control over virtual behavior, and whether some reverse-PInvoke behavior should be applied in the form of a thunk that eventually dispatches to the managed method. If we are performing an unmanaged->managed transition, you also have some control over which AppDomain should be selected for us to dispatch the call. However, one of these options (COR_VTABLE_FROM_UNMANAGED_RETAIN_APPDOMAIN) doesn't exist in V1. We added it in V1.1. There are several reasons we haven't provided a baked-in, verifiable, CLS-compliant version of multiple implementation inheritance: 1. Different languages actually have different expectations for how MI works. For example, how conflicts are resolved and whether duplicate bases are merged or redundant. Before we can implement MI in the CLR, we have to do a survey of all the languages, figure out the common concepts, and decide how to express them in a language-neutral manner. We would also have to decide whether MI belongs in the CLS and what this would mean for languages that don't want this concept (presumably VB.NET, for example). Of course, that's the business we are in as a common language runtime, but we haven't got around to doing it for MI yet. 2. The number of places where MI is truly appropriate is actually quite small. In many cases, multiple interface inheritance can get the job done instead. In other cases, you may be able to use encapsulation and delegation. If we were to add a slightly different construct, like mixins, would that actually be more powerful? 3. Multiple implementation inheritance injects a lot of complexity into the implementation. This complexity impacts casting, layout, dispatch, field access, serialization, identity comparisons, verifiability, reflection, generics, and probably lots of other places. It's not at all clear that this feature would pay for itself. It's something we are often asked about. It's something we haven't done due diligence on. But my gut tells me that, after we've done a deep examination, we'll still decide to leave the feature unimplemented.

Chris, I started to play with SOS extensions, and gives a lot of info about some domains, heaps that I've never heard of before. Could you please explain GC Heaps and Domain I more details than available in docs.

Thanks for an amazing blog Chris, its the best source of technical .NET information I've seen anywhere! I've got one little question for you. Is there any way to provide more customization of the assembly resolver than handling the (last-chance) AppDomain.AssemblyResolve event? Any chance we'll see something similar to the JVM programable class loader sometime in the future? I imagine there are lots of nasty scenarios where this flexibility could create confusion and problems, but I believe there may be a few scenarios (eg. mobile code) where having this ability would be beneficial.

Chris, does the CLR have a single barrier (or locked section, ...) where the memory allocator and the GC have to interlock on an app-domain wide basis, even for a short period of time? If not, how do you avoid it? If so, does this barrier become the ultimate limit on the number of small objects that can be allocated and collected per app domain per unit time? (I think that would be a function of CPU speed or memory architecture in real time...maybe a constant in processor-virtual time?) Any thoughts about this would be appreciated, and I want to join everybody else in thanking you for the great work on this blog. It is truly illuminating.

Hi, Chris. 2 topics that seem to be not yet covered anywhere else: 1) How transparent/real proxy stuff works - how CRL creates them, etc. And wy interception is so slow compared to raw calls. Any plans to implement light-weight interception? 2) I heard CLR is changing dispatch mechanism (from v-table to stub-based ???). It'd be intersting to know why by comparing both mechanisms. Thanks, Ilya

Fantastic stuff! I'm extremely impressed with your omnipotent .NET presence. One topic that I’m really interested in…is remoting. Listening to Carl Franklin’s .NET Rocks radio program Ingo Rammer was mentioning something about using named pipes and remoting. Do you have any knowledge to this or some nice examples of this? Additionally and topics on implementing a Real Proxy in a load balanced environment would be most excellent! Thanks, Eric F. Cotter DevIdiom Inc

Hi Chris can you talk about RCWs and CCWs , epecially the RCWs ,how they hold on to the context info (cookies) , how and when are they cleaned up ? when a com object behind the RCW is destroyed what happens to RCWs and the info they hold ,context etc..,are they cached/reused? CCWs are they subject to GC?

Hi Chris, I'd love to hear more about thread synchronization in .NET, including some of the reasoning behind the way things were done. For example, some people have argued (eg. Jeff Richter at http://msdn.microsoft.com/msdnmag/issues/03/01/net/default.aspx) that having a 1:1 correspondence between objects and monitors was a bad idea. I haven’t heard enough about the benefits of this approach to form a strong opinion, but there are some obvious disadvantages to enforcing a physical relationship between an object and the monitor used to synchronize access to that object. The classic example is that the lock must have the same protection level as the object, which is often undesirable. I assume there are some big advantages to justify the overhead of giving every object a sync block index, even though a large majority of objects will never need to use it (I’ve heard that the sync block index is also used for the GC mark bit and the default object hashcode somehow). Its also not totally clear to me when I should use Monitor.Wait/Pulse instead of an AutoResetEvent, or what the relative performance implications are. Thanks! Rick

Hi Chris, It's me again ! Thanks for the answer on MI inheritance in classes ... I understand why bringing in MI into the CLR or any runtime, VM supporting multiple languages and spanning various features like casting, serialization, reflection and generics will be a very conscious and important design decision that will determine the critical success of the framework itself. Well anyway, i would have been one of those happy people if atleast C# had that feature, like in the case of generics in whidbey ! Thanks a zillion chris ! Vijay

You've mentioned "clever" lock-free thread-safe code in passing... but you've never written a blog specifically on key CLR implementation issues supporting concurrency constructs. Discussion of things like the main synchronization and communication mechanisms and how they impact things like GC and serialization. -I've enjoyed your insights into mistakes made, lessons learned, and the nasty things to tag with "Danger thar be Dragons". Perhaps this might be a topic worth consideration?

Chris, The question that is always in my head why I write C# code is as follows: Why there is no const methods, const parameters and all the related stuff in .NET (language or runtime)? This would help a lot to be able to tell compiler and runtime whether I'm going to modify object inside a method or not, add chances to optimize the code and avoids numerious problems with boxing and operating on a copy of value-type object. Also check Peter Golde's post concerning mutable structs (http://peter.golde.org/2003/11/04.html#a20) and my comment there.

A .NET Riddle.

Chris
I have been facing one problem lately.
I have to fire a Oracle stored procedure from an ASP.NET application. I am using Microsoft.NET Data Provider for Oracle Sometimes this procedure takes more than 5 mins to execute and the web application throws a ThreadAbortException . I know that ASP.NET maintains a request pool for the requests made, and removes them from the pool once the response is sent to the client.I suspect that timeout is occuring and the RequestTimeoutManager is aborting the thread.
Could you give me some pointers , as regarding where I should focus on the Oracle side.If possible is there any better way to call such long running services
Any help would be greatly appreciated
Cheers
Hriday

Chris

Our .Net team have been pondering about using keyword.

We are using streams FileStream and BufferedStream. We use using keyword at FileStream, and not BufferedStream which wraps FileStream. So bunch of people said what if exception occurs buffered stream is not closed.

My Argument is over advantages of using 'Using' keyword.

First Advantage being -- Using used for Dispose (Deterministic Finalization) to free resources earlier, than later. Dispose and Close do the same thing.

Second Advantage being all objects in using will have priority in Gargbage collection ! - Is this statement valid?

So my justification was if file stream is grabage collected, there is no need to use Using keyword on BufferedStream.

Pl shed some light on this.
Thanks Very much.
Mehul.

Ilya, I spoke briefly about managed 'const' in my blog about exceptions. Here's that excerpt:

To me, this is rather like ‘const’ in C++. People often ask why we haven’t bought into this notion and applied it broadly throughout the managed programming model and frameworks. Once again, ‘const’ is a religious issue. Some developers are fierce proponents of it and others find that the modest benefit doesn’t justify the enormous burden. And, once again, it must be applied broadly to have value.



Now in C++ it’s possible to ‘const-ify’ the low level runtime library and services, and then allow client code to opt-in or not. And when the client code runs into places where it must lose ‘const’ in order to call some non-const-ified code, it can simply remove ‘const’ via a dirty cast. We have all done this trick, and it is one reason that I’m not particularly in favor of ‘const’ either.



But in a managed world, ‘const’ would only have value if it were enforced by the CLR. That means the verifier would prevent you from losing ‘const’ unless you explicitly broke type safety and were trusted by the security system to do so. Until more than 80% of developers are clamoring for an enforced ‘const’ model throughout the managed environment, you aren’t going to see us added it.

Mehul,

The use of 'using' only affects garbage collection indirectly, due to the fact that Dispose calls SuppressFinalize on the instance.

Garbage collection is always based on reachability, though the generational scheduling of the collections means that objects may not be collected for an indefinite delay after they become unreachable.

Finalization causes objects to remain reachable for an additional delay, as described in my blog on Finalization. The fact that 'using' typically results in SuppressFinalize means that it can prevent that delay.

As to your specific questions on BufferedStream and FileStream, I'm certainly no expert on the IO classes. But if you Dispose the FileStream without Dispose'ing the BufferedStream that wraps it, won't you skip the Flush operation in BufferedStream.Close?

Ranjan,

I'm afraid this is a better question for the System.Data or ASP.NET teams. It wasn't obvious to me whether the 5 minute delay is expected or unexpected. If it is expected, I think you need to increase the ASP.NET request timeout value, to avoid the Abort. If it is unexpected, I wonder if the operation is cache-able so that you could satisfy the query during request processing without enduring the delay. And of course there are the obvious ideas like adding an index to your database schema to improve performance.

PingBack from http://backyardshed.info/story.php?title=cbrumme-s-weblog-request-a-topic

PingBack from http://workfromhomecareer.info/story.php?id=30509