Dino's Blog

Announcing Python Tools for Visual Studio 1.0

DinoV — Wed, 31 Aug 2011 20:25:01 GMT

As you can see from Soma's blog on Monday we released Python Tools for Visual Studio 1.0. Of course I'm excited about this release as it's been the 1st stable release I've put since IronPython 2.6 (and the first blog too!). This release of PTVS focuses on a combination of the core IDE experience (intellisense, debugging, profiling, code navigation, etc..) as well as a set of features which target Technical / High Performance Computing. That includes support for MPI cluster debugging and integrated IPython support.

PTVS has been a long time in the making and it represents the fruition of a lot of effort here at Microsoft to produce a Python IDE. This actually goes back a long time starting it's development several years ago on the IronPython team. Back then we had done several small projects to figure out what we'd want to do in the Python IDE space. That included a couple of attempts of building a stand alone IDE using the same components Visual Studio is built upon as a few different attempts at extending Visual Studio to add Python support (some of this having seen the light of day in the form of IronPython Studio and the Python integration which ships w/ the VS SDK). Ultimately we were able to re-use bits and pieces from all of these attempts and release IronPython Tools for Visual Studio w/ the Alpha of IronPython 2.7.

But we needed one last push to turn PTVS into what you see today - and that final push brought support for more than just IronPython and we now have turned Visual Studio into a general purpose Python IDE. Whatever version of Python you'd like to use I think you'll find that PTVS provides a great experience - whether you're using traditional CPython or IronPython (which we still have special support for including WPF designer support) or another Python distribution such as the speedy PyPy. The only feature which doesn't currently work across Python distributions is the profiling support which for performance reasons is tied to the CPython embedding API.

Anyway, if you're looking for doing Python development on Windows I hope you'll give PTVS a shot and let us know what you think.

IronPython 2.6 Released!

DinoV — Fri, 11 Dec 2009 23:44:00 GMT

I've very happy to announced that we've officially released IronPython 2.6! This is a great release which brings us up to date with the stable CPython 2.x branch, greatly improves startup time performance, continues to improve our support for deep .NET integration, adds major new features like pdb and sys.settrace support, and as usual we've fixed a ton of bugs along the way. It's also identical to RC3 in every way so if you've already installed RC3 you're ready to go! If not you can download it now from CodePlex: http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=12482

Here's the full release notes if you'd like more details about what's changed:

Hello Python Community,

We’re proud to announce the release of IronPython 2.6 final. This is a major release with improvements across all areas of IronPython and can be downloaded from http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=12482. Significant changes include:

· Updating the language and standard library to match CPython 2.6

· Improved .NET integration

· Updating to the latest version of the DLR

· Adding previously missing CPython features and fixing bugs

· Performance improvements in particular startup time improvements

Python 2.6 support includes a large number of new features which include support for the new bytes and byte array types (PEP 3112), decorators for classes (PEP 3129), advanced string formatting (PEP 3101) which will feel familiar to .NET users and integrates nicely with IFormattable, print as a function (PEP 3105), Abstract Base Classes (PEP 3119), support for binary literals, along with lots of other minor features and changes.

IronPython also continues to improve .NET integration in this release. We’ve added the __clrtype__ method to types which enables deep integration via meta-classes with the .NET type system. There are also a number of smaller changes such as supporting IDisposable in for loops matching the behavior of other .NET languages. This release also includes the latest version of the DLR and fixes a number of issues related to cross-language dynamic interop. Not to be left out there’s improvements in Silverlight integration by supporting Python code in HTML script tags.

We’ve also continued to improve Python compatibility by adding missing features and fixing bugs. In this release we’ve added support for the ctypes module which provides interop with native code in a compatible way across Python implementations. We’ve also implemented sys.settrace to provide support for the pdb module and other Python debuggers. This release also changes how we support sys._getframe: a fully working version is now available by a command line option; when not enabled sys._getframe doesn’t exist at all. This release also fixes over 400 bugs removing a large number of smaller incompatibilities.

As always we’ve also continued to improve performance, and this release primarily focuses on improving startup time. The IronPython installer now pre-compiles (ngens) IronPython during installation on both 32-bit and 64-bit platforms. Modules are now interpreted initially and hot functions are compiled for faster import times. A number of other code paths that used to involve runtime code generation have been optimized to be contained within the pre-compiled IronPython binaries. We’ve also made a number of smaller changes which improve performance in other areas such as adding constant folding.

Finally we’d like to thank everyone who reported issues and helped make this a better release: Anders M. Mikkelsen, Dan Eloff, Zachc, yamakox, vernondcole, VAks, tscottw, tonyandrewmeyer, tomwright, TomasMatousek, tkamiya, timers, srivatsn, sopeajw, saveenr, sanxiyn, rridge, ronniemaor, quirogaco, pythonfoo, pysunil, pm100, pl6306, paulfelix, orestis, olegt, oldman, NDHUMuscle, mycall, mmaly, mmacdonaldssfcu, maplpro, luntain, llaske, lbaker, Lawouach, laurionb, laughingboy, kurhan, kuno, kowenswp, klrohe, kevgu, jmesserly, jlunder, jdhardy, jbevain, jackeyoo, hhonisch, gz, gjones, fwereade, deadalusai, daveremy, Seo Sanghyeon, CurtHagenlocher, chaghi, cgravill, cartman, bobarnso, atifaziz, ashcor, alvanet, Helmut, fuzzyman, fabiofz, Eloff, RuiDC, Kevin Chu, Kyle Howland-Rose egonw, davec, dungen, dsblank, cjacobs, dmajnemer, leppie, Mark Rees, soulfry, tatwright, ufechner and wilberforce.

Thank you for your continued support of IronPython.

The IronPython Team

World's Worst Paint Program

DinoV — Tue, 17 Nov 2009 21:58:00 GMT

I've uploaded the World's Worst Paint Program, as seen in my PDC talk, to IronPython's CodePlex site:

http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=28125#DownloadId=93331

This is built using Visual Studio 2010 Beta 2 and the IronPython CTP for that release - so you'll need to download both of those. I've also included the Python and Ruby code that I used during the demonstration in a file called code.txt. The paint program it's self is in the final form at the end of the demo.

Two IronPython releases in 1 week

DinoV — Thu, 23 Jul 2009 20:04:00 GMT

This was a good week for IronPython - we've released not one but two new versions!

The first release was IronPython 2.0.2 which just includes bug fixes for issues which have been particularly irritating to our users. This is a very minor release and doesn't include breaking changes. Probably the most significant fix is that we've fixed ngen on 64-bit platforms. Previously when you would install 2.0 and enable ngen it would only ngen the binaries for 32-bit assemblies. Now we'll ngen for 64-bit which should help users running on 64-bit see much faster startup times. I hope that this will make 2.0 much more usable until we get the really big improvements that 2.6 brings.

And speaking of 2.6 the other release this week was our 2nd and final beta. 2.6 is shaping up to be an exciting release. We've significantly improved the startup time of IronPython - this has been our number one requested change. We've implemented more standard modules and other missing functionality to be closer to CPython. This includes the new ctypes module, support for sys.settrace and pdb, as well other new functionality that 2.6 has introduced such as the underlying support for the io module. And finally we've added a bunch of new features to improve .NET interop as well - we've now got support for generic method type inference and added the core support that will enable using .NET attributes and in general working better w/ .NET when static types are expected. I'm pretty excited about this release and can't wait to get the final version out - so please try out this beta and let us know if you run into any issues.

On Performance

DinoV — Sat, 23 May 2009 00:23:00 GMT

Ahh, performance… It’s so much fun! It’s easy to measure and as you work on it you can see immediate benefits (or not!). I personally enjoy getting to spend time looking at interesting performance issues and I’ll use this as a time to plug IronPython 2.6 Beta 1 where we’ve continued our focus in this area. Even more fun yet is when you compare and contrast different implementations - it can be both surprising and amusing. Recently Robert Smallshire has been doing just that: http://www.smallshire.org.uk/sufficientlysmall/2009/05/22/ironpython-2-0-and-jython-2-5-performance-compared-to-python-2-5/ Obviously Robert has found a case in IronPython where something is performing horribly. I’d like to take a look at what’s happening here and what we can do to improve this case.

But before I look at what’s going on here I’d like to briefly say we love to hear feedback from users of IronPython. We’ve have a mailing list you can join and give us your feedback on and bugs can be reported on our website. We track both of these very closely and respond as quickly as we can – which is usually pretty fast. I just mention that because it’s easier for us to improve IronPython when people let us know about a problem vs. us having to scour the web to find issues. Hopefully this piqued interest will have more people trying out IronPython and giving us feedback.

Ok, but let’s get onto the fun technical details! It all comes down to one line of code “Node.counter += 1”. That’s a pretty innocent looking piece of code, how can it cause so many problems? First you need to understand a little bit about how IronPython works. IronPython internally keeps versions of type objects and uses this information to generate optimal code paths for accessing those objects. So the next line of code in this example, “self._children = children” usually turns into something that’s like:

if (self != null && self.GetType() == typeof(PyObject) && self.PythonType.Version == 42) {

self._dict["_children"] = <new value>;

}

What that one line of code causes then is for the version of the type to change and for this “rule” to be invalidated. So we’ll figure out what to do, generate a new cached rule, only to have it not work the next time around. The same thing applies to the calls to Node – we re-generate the “optimal” code again and again only to discover we have to throw it away.

So that sounds pretty bad but if you’re familiar with Python’s member access rules you’ll quickly recognize that this will be much faster than needing to do the resolution again and again. That involves looking through the class hierarchy to see if we have any data descriptors or classes defining __setattr__ and it's nice to avoid all of that work. So to get the best performance we require for the world to settle down and not be continuously changing. We’re well aware of this problem with our implementation and we have continued to focus on improving it. IronPython 2.0 already includes one mitigation so that we don’t need to continuously generate new code – instead we effectively patch new values into an existing piece of code. In our IronPython 2.6 branch we’ve continued to improve performance here and significantly reduced the expense when things get mutated. But it turns out that there’s an easy fix for this particular problem we’ve just never thought it that important of a problem to solve.

One of the amusing things about this is we’ve actually seen it before – Resolver Systems was having some performance issues with Resolver One which is their advanced spreadsheet which is written in IronPython. One of those issues turned to be a type which they both used frequently and mutated frequently. This actually doesn’t seem to be a common idiom in Python code which is the reason we’ve never optimized for it before. In this case though it turned out that they had found an optimization that improved performance on IronPython 1.0 but was destroying perf on IronPython 2.0! For Resolver fixing this was a simple change for them to no longer mutate types. Even if you really want to use a type as a property bag you can always move that to a type which you aren’t creating instances of and executing methods on.

With all that in mind let’s look at some numbers. Here I’ve compared IronPython 2.01, IronPython 2.6 Beta 1, CPython 2.6 plus IronPython 2.6 with a fix for this issue.

Like Robert’s charts I have tree size in number of nodes across the bottom and execution time in seconds across the top and the execution times are logarithmic. We can see the abysmal performance of 2.0.1, we can see that 2.6B1 has already made significant improvements, and with IronPython 2.6B1 plus a fix for this specific issue we actually beat CPython as the number of iterations scales up.

But there’s another way we can look at this – instead of fixing IronPython let’s look what happens if we fix the benchmark to avoid this performance pitfall. To do this I’ve replaced the mutation of the class with a global variable. When running against all of the same implementations again I get these results:

Here you can see that all 3 versions of IronPython are performing about the same and are coming in significantly faster than CPython as the number of iterations goes up. These are now also matching the numbers Robert is getting when he has made the same change.

So you might be curious - what’s the fix? Well in this case we’re just mutating the type by changing a simple value stored in the type (versus say adding a property or a method to the type). Today we get a very slight throughput performance benefit because we can burn the value directly into the generated code instead of fetching it from the wrapper the type object keeps it in. With the fix we’ll burn the wrapper in and fetch the value from the wrapper each time. Then when we go and modify the type we just modify the wrapper instead of the type and its version is unchanged! This fix is now checked into the IronPython source tree and you can download the fixed sources right now.

In conclusion I’d like to wrap up a little bit about our performance philosophy – performance is hard and deciding which numbers matter to you is important. We have tried to tune IronPython for apps which run for more than a fraction of a second. We have also tuned IronPython for code which is not constantly mutating types at runtime. And we’re always open to feedback when users encounter problems with IronPython and we’ll listen to what scenarios are important for them. But if you look at these graphs I think you can see that we’ve done a good job at making IronPython a fast implementation of Python.

A Simple DLR Binder

DinoV — Thu, 22 Jan 2009 06:11:00 GMT

A lot of people find it a little confusing to write their first binder to consume dynamic objects running on the DLR. It’s not actually super simple but it’s not too hard either. To shine some light on this I thought I’d post a very simple binder that shows how you plug in. This example just supports adding 2 ints. If the target object is an IDynamicObject the object will get the first crack at implementing the operation. So for example a class written in IronPython which implements __iadd__ will call the __iadd__ method to do the addition (ok, that’ll be true once I support the current DLR way of doing operations, we’re still using an older version). For objects of any other types which don’t implement IDynamicObject it will report an error indicating the types and the operation kind. Even if you specify a different operation kind it will still just add ints.

There’s a few key pieces you need to understand here. First you’re returning an expression tree back to the DLR to tell the DLR what to do. The DLR will compile this expression tree and run it. You’re also returning a set of “restrictions”. These will be evaluated by the DLR to see if it can re-use the same code for other objects in the future. You’re unlimited in what you can do with restrictions as they can be arbitrary Expression trees. But here I’m simply restricting based upon the arguments .NET types which is one of the most common restrictions. Both the expression tree and restrictions get packaged up in a DynamicMetaObject which is conveniently the same type of object you receive as your arguments.

Finally there’s the hash identity which is how the DLR knows if it can share rules or not amongst different binders. The base DLR binders override GetHashCode/Equals to hash on the operation, member name, etc… depending on the binder type so I just return this here.

So here it is a simple binder. This targets the latest and greatest DLR sources which has experienced some renames and so isn’t compatible with IronPython 2.0. But you can always get the latest IronPython source code which this will compile against at http://www.codeplex.com/IronPython/SourceControl/ListDownloadableCommits.aspx

class MyOperationBinder : BinaryOperationBinder {

public override DynamicMetaObject FallbackBinaryOperation(DynamicMetaObject target, DynamicMetaObject arg, DynamicMetaObject errorSuggestion) {

if (target.LimitType == typeof(int) && arg.LimitType == typeof(int)) {

return new DynamicMetaObject(

Expression.Add(

Expression.Convert(target.Expression, typeof(int)),

Expression.Convert(arg.Expression, typeof(int))

BindingRestrictions.GetTypeRestriction(target.Expression, typeof(int)).Merge(BindingRestrictions.GetTypeRestriction(arg.Expression, typeof(int)))

);

}

return new DynamicMetaObject(

Expression.Throw(

Expression.New(

typeof(Exception).GetConstructor(new Type[] { typeof(string) }),

Expression.Constant(

String.Format("Can't perform operation {0} on {1} and {2}", this.Operation, target.LimitType, arg.LimitType)

)

BindingRestrictions.GetTypeRestriction(target.Expression, typeof(int)).Merge(BindingRestrictions.GetTypeRestriction(arg.Expression, typeof(int)))

);

}

public override object CacheIdentity {

get { return this; }

}

IronPython, MS SQL, and PEP 249

DinoV — Mon, 17 Mar 2008 20:18:00 GMT

Over the past week and a half I've spent a little bit of time getting Django 0.96.1 running on IronPython. The 1st step in doing this was getting a database provider that would run on .NET that would work with Django. For DB backends Django basically follows PEP 249 with a few extensions. Here's the basic DB provider I came up with. It's not quite complete but it was good enough for me to get Django's tutorial running. To use this you just need to copy one of the existing DB backends and replace the code in base.py with the code below. For the rest of the code you can pull it from ado_mssql.

Basically this just uses the .NET System.Data namespace to do the communication with the database server.

import clr
clr.AddReference('System.Data')
from System import Data
from System.Data import SqlClient
import System

DatabaseError = Data.DataException

from threading import local

class SqlCursor(object):
    arraysize = 1

    def __init__(self, connection):
        self.connection = connection
        self.transaction = None
        self.reader = None
        self.record_enum = None

    def execute(self, sql, params=()):
        parameters = []

        # translate to named parameters
        if type(params) in (list, tuple):
            # indexed params, replace any %s w/ @GeneratedName#
            if sql.find('%s') != -1:
                cmd = ''
                sqlSplit = sql.split('%s')
                for text, value, index in zip(sqlSplit, params, range(len(params))):
                    cmd += text + '@GeneratedName' + str(index)
                    parameters.Add(SqlClient.SqlParameter('@GeneratedName' + str(index), str(value)))

                sql = cmd + sqlSplit[-1]
        else:
            for name, value in params.iteritems():
                sql = sql.replace('%(' + name +')s', '@' + name)
                parameters.Add(SqlClient.SqlParameter('@' + name, str(value)))

        command = SqlClient.SqlCommand(sql, self.connection)

        for param in parameters: command.Parameters.Add(param)

        self.record_enum = None
        self.reader = command.ExecuteReader()

    def close(self):
        self.reader.Close()

    def executemany(self, sql, param_list):
        res = []
        for s in sql:
            res.append(execute(s, param_list))
        return res

    def fetchall(self):
        return [self._make_record(record) for record in self.reader]

    def fetchone(self):
        if self.record_enum is None:
            self.record_enum = iter(self.reader)
        if self.record_enum.MoveNext():
            return self._make_record(self.record_enum.Current)
        return None

    def fetchmany(self, size=None):
        if size is None: size = SqlCursor.arraysize
        res = []
        for i in range(size):
            x = self.fetchone()

            if x is None: break

            res.append(x)
        return res

def _make_record(self, record):
return tuple((self._fix_one_record(record[i]) for i in xrange(record.FieldCount)))

    def _fix_one_record(self, record):
        if type(record) is System.DateTime:
            return datetime.datetime(record)

        return record

    @property
    def rowcount(self):
        if self.record is not None:
            return self.reader.RecordsAffected
        return -1

class DatabaseWrapper(local):
    def __init__(self, **kwargs):
        self.connection = None
        self.queries = []
        self.transaction = None

    def cursor(self):
        from django.conf import settings
        if self.connection is None:
            if not settings.DATABASE_HOST:
                settings.DATABASE_HOST = "(local)"
            if settings.DATABASE_NAME == '' or settings.DATABASE_USER == '':
                conn_string = "Data Source=%s;Initial Catalog=%s;Integrated Security=SSPI;MultipleActiveResultSets=True" % (settings.DATABASE_HOST, settings.DATABASE_NAME)
            else:
                conn_string = "Data Source=%s;Initial Catalog=%s;User ID=%s;Password=%s;Integrated Security=SSPI;MultipleActiveResultSets=True" % (settings.DATABASE_HOST, settings.DATABASE_NAME, settings.DATABASE_USER, settings.DATABASE_PASSWORD)

            self.connection = SqlClient.SqlConnection(conn_string)
            self.connection.Open()

        cursor = SqlCursor(self.connection)
        if settings.DEBUG:
            return util.CursorDebugWrapper(cursor, self)
        return cursor

    def _commit(self):
        if self.transaction is not None:
            return self.transaction.Commit()

    def _rollback(self):
        if self.transaction is not None:
            return self.transaction.Rollback()

    def close(self):
        if self.connection is not None:
            self.connection = None
            self.transaction = None

New opportunities...

DinoV — Thu, 17 Nov 2005 23:24:00 GMT

After a little over 4 years it’s time for me to go and explore new opportunities… It's awesome to see Whidbey out there now and I'm sure the work we did to improve the reliability of the CLR and embed it in SQL Server will pay off for our customers. But it's time for me to go and try something new - so I'm switching from the CLR team to... join the CLR team :).

I'll be switching from my current test role over to development to work on on IronPython and improving the CLR's support for scripting languages in general. I started on the new team last Monday and it's already been a lot of fun. Today we've shipped our first release since I joined (0.9.5 - which you can download here. While this is the first release since I've joined the team it's the second release to which I've contributed. This release brings a bug fixes, support for several new built-in types and improvements when using Python objects from WPF.

So expect to see less about reliability and hosting (when I post :) ) from me over time and more about IronPython and scripting. I still have some more I want to say about reliability and hosting so there should be an interesting mix going forward.

Anyway, I encourage everyone to check out our latest release and let us know what you think!

Fiber mode is gone...

DinoV — Thu, 15 Sep 2005 23:38:00 GMT

Well, now that our RTM and RC-esque builds are starting to make it out into the wild it seems like a good time to discuss a feature we had to make go away...

That feature which most readers of my blog are probably now familiar with is fiber mode. So why did we cut fiber mode for the released version of the product? And what changes will you see because of this?

We had gone through great efforts to make sure that all of our core functionality worked great inside of a fiber mode host. Not only did the CLR team do a lot of work to make sure fiber mode was solid, but so did many other teams who picked up our toolset and verified that worked properly by running their tests inside of fiber mode. Not to mention the teams that typically run their tests inside of Yukon who also make sure their features work in fiber mode. We even spent extra time at the end of beta 2 to make sure we got all the last minute fiber bugs fixed from our full fiber mode test pass - but ultimately it wasn't enough.

In the end we had one final exit criteria we'd have to pass in order to make sure fiber mode was solid: Stress. Between the choices of spending our time fixing the bugs that we knew ALL of our customers would hit in thread mode, or fixing the bugs that a small percentage of users would hit in fiber mode, we picked fixing thread mode bugs. In the end I think most customers will be happy as the SQL and CLR teams came together and we've spent a huge amount of time, resources and effort ensuring that SQL/CLR works great under thread mode.

For those of you wanting to develop a fiber mode CLR solution I think you need to first ask yourself why you're doing this. If you're attempting to conserve stack space then this is not the solution you're looking for. If you're attempting to reduce the number of context switches experienced then you can still get much the same results using thread mode and blocking "switched out" tasks on an event that gets signaled when it's their turn to run. And of course there's a 3rd, although usually less desirable, option to redesign the way you're approaching the problem of a large number of work items.

Finally what are the changes in removing fiber mode? Surprisingly everything will work exactly the same as it did in pre-RC and RTM builds except for one API will now return E_NOTIMPL. That one API is ICLRTask::SwitchOut. You still can do all the interesting stuff with integrating the CLR task management with your own environment, and you can still switch a logical task in on a thread that previously had another logical task running on it, but you can't switch out a logical task during the middle of its lifetime.

I realize removing this feature will cause some of you some pain but I hope you'll see that this was the right call for us to get a super stable Whidbey out the door in a reasonable timeframe.

Cooperative Fiber Mode Sample - Day 11

DinoV — Mon, 11 Oct 2004 22:57:00 GMT

Last week we went over the Abort and RudeAbort APIs. This week we’ll go over Fiber.Exit. This API provides a way for you to terminate a running fiber, and demonstrates a use of the unmanaged ICLRTask::ExitTask API. The ExitTask API can only be called on a fiber that is currently switched in which gives us a similar problem to what we had in Abort/RudeAbort. But because the ExitTask call will not block for a long period of time we handle it a little differently than Abort and RudeAbort.

After checking & updating our state like we did in Abort and RudeAbort, the ExitTask API does:

if (this == Fiber.CurrentFiber)

{

// exiting a running task is easy

InternalExitTaskAndThread(fiberAddr);

}

else

{

// only tasks that are running can call ICLRTask::ExitTask.

// We need to switch the task in, call ExitTask, and then

// switch back to our current fiber.

InternalExitTaskAndSwitch(fiberAddr, Fiber.CurrentFiber.m_fiberAddr);

}

Here you can see we take one of two actions. Either we call InternalExitTaskAndTherad() which will cause both the current thread and fiber to exit, or we call into InternalExitTaskAndSwitch.

The first call is pretty self-explanatory. We’re the current thread, we want to let the whole thing die off – this is exactly the same to calling DeleteFiber on the currently running thread.

The second call is a little different. Here we have a fiber that is currently switched out. We want to re-schedule the fiber we’re asking to exit, call ExitTask on it, and then switch back to our previously running fiber. Here we go back to the code in SwitchIn that we looked at in article 4:

if(curTask->FlagCheck(TASK_FLAG_EXITING))

{

_ASSERTE(curTask->GetSwitchingTo());

curTask->ExitTask();

curTask->GetSwitchingTo()->SwitchIn();

}

The task has been requested to exit, we call ICLRTask::Exit on it, and then we switch back to the previously running task having completed the work the user requested.

One note worthy point here is that like the DeleteFiber APIs, the ExitTask API is potentially unsafe. This is because we’re exiting the thread with code higher us still on the stack. This code may have resources to free or other state to clean up. Typically a host would only call ExitTask after all managed code has left the stack.

That brings us to the end of the CoopFiber series. We’ve gone over the smallest set of APIs that are required for implementing fiber mode. We’ve then exposed the APIs to the managed code author to allow them to be in control of the scheduling. To implement a scheduler on top of this would require updating the synchronization primitives so they’d select new tasks and switch them in instead of blocking the thread. And hopefully you’ve walked away from all of this with a better understanding of the interactions between the CLR and the host when running in fiber mode.

Cooperative Fiber Mode Sample - Day 10

DinoV — Fri, 01 Oct 2004 00:15:00 GMT

In this article we’re going to look at the implementation of Abort and RudeAbort. In the last article I mentioned that a typical host wouldn’t need to expose these to managed code. Why is that? If you have a fiber mode scheduler typically Thread.Abort will be sufficient. Your scheduler will eventually schedule the task, and the task will then be aborted.

But in the CoopFiber sample we don’t have a scheduler. Therefore a user could call Thread.Abort on a switched out fiber, and it would never get scheduled to be aborted. What’s worse is that the call into ICLRTask::Abort will block until the thread gets scheduled again.

To handle this peculiarity when an Abort request comes in the Fiber class first determines whether the task is running or not. If it is already running then we’ll go ahead and abort it right away. Otherwise we’ll set a bit to notify that on the next switch we should abort the task. Here’s the Fiber.Abort implementation:

bool fAbortNeeded = false;

lock (m_syncObj)

{

m_FiberStates |= FiberStates.AbortRequested;

if ((m_FiberStates & FiberStates.Running) != 0 && (m_FiberStates & FiberStates.Switching) == 0)

{

//the current fiber is aborted, so we can initiate the abort now.

fAbortNeeded = true;

}

if (fAbortNeeded)

{

InternalAbort(m_fiberAddr);

}

InternalAbort will just turn around and call ICLRTask::Abort on our already switched in task. In our last article we saw our calls to CheckForAbort during task switch in. That code simply looks like:

// Next see if the user requested an abort on this thread.

if ((m_FiberStates & FiberStates.AbortRequested) != 0)

{

Abort();

}

else if ((m_FiberStates & FiberStates.RudeAbortRequested) != 0)

{

RudeAbort();

}

We simply call back to Abort or RudeAbort, which will then call into InternalAbort to finally Abort/RudeAbort the task. The task is now switched in and running so we’ll call into the host to perform the actual abort (which now won’t block because the task is running).

At this point you may be asking yourself “What is this Rude Abort thing?” Rude aborts are actually a new Whidbey feature, and can be accessed one of several ways. The only difference between a rude abort and a normal thread abort is that the rude abort will not execute your catch/finally blocks. In addition to being exposed directly through the hosting APIs rude abort’s can also occur due to escalation policy (also configured via the hosting APIs). That’ll have to be saved for another blog entry…

CoopFiber’s Rude Abort implementation is essentially identical to the Abort implementation. The only difference is that we’ve replaced the work Abort with RudeAbort everywhere.

So that’s it for the Abort/Rude Abort implementation. We’ve almost reached the end of this serious, but there’s one last API that’s worth covering on the managed size: Fiber.Exit. I’ll go over that implementation next article.

Cooperative Fiber Mode Sample - Day 9

DinoV — Thu, 16 Sep 2004 22:24:00 GMT

The managed Fiber class exists in its own directory in the SDK sample appropriately called Fiber. The Fiber class is designed to be vaguely similar to the managed Thread class. For example, like the Thread has ThreadState the fiber has FiberStates.

The managed fiber class exposes a few significant APIs:

· public static Fiber CreateFiber(FiberStart fs)

· public static Fiber CurrentFiber

· public void SwitchTo()

· public void Abort()

· public void RudeAbort()

· public void Exit()

· public FiberStates FiberState

The CreateFiber API should be obvious. It takes a FiberStart delegate and passes it into the unmanaged InternalCreateFiber API we previously looked at.

CurrentFiber is nearly just as obvious: We store the current fiber in managed thread local storage (or in our case it’s really fiber local storage) so we can easily fetch it. If we haven’t created a managed Fiber object for this fiber yet we’ll get it from the host via a P/Invoke into the InternalGetCurrentFiber API. This simply gets the currently executing CHostTask, AddRef’s it, and returns it. The managed half simply sticks this into our SafeHandle to ensure it’s properly cleaned up.

The last trivial method here is FiberState. This just returns m_FiberStates which the managed Fiber class maintains as the fibers switch through various states.

The interesting APIs here though are actually SwitchTo, Abort, and RudeAbort. We’ll start at looking at SwitchTo.

The first thing we watch out for in the managed implementation is that we don’t try and switch a fiber in on 2 threads:

Fiber curFiber = CurrentFiber;

lock (m_syncObj)

{

if ((m_FiberStates & (FiberStates.Running|FiberStates.Switching)) != 0)

{

throw new FiberStateException("Attempt to switch to a fiber that is running or already switching!");

}

m_FiberStates &= (~FiberStates.Unstarted);

m_FiberStates |= FiberStates.Running;

}

If the fiber was already running, or is currently involved in a switch, then we’ll throw an exception that you cannot currently switch. We’ll then update the fiber we’re trying to switch in so it’s now officially running (this will prevent anyone else from switching it in).

Next we need to make sure that no one races in and tries switching in the fiber we’re switching away from.

lock (curFiber.m_syncObj)

{

m_FiberStates |= FiberStates.Switching;

}

// we've marked us as switching, do one last check to see if someone wanted to abort us.

// Anyone after this will get us aborted on our next switch in.

CheckForAbort();

So we update its state to mark that it’s currently switching out. You’ll also notice we’re checking to see if we need to abort a thread. We’ll cover this more in-depth in the next article where I discuss the Abort & RudeAbort implementation.

m_prevFiber = curFiber;

// switch in the fiber the user requested

InternalSwitchIn(m_fiberAddr);

curFiber.OnFiberSwitchIn();

Next we mark what the previous fiber was (we’ll need to update it to remove the Running & Switching bits), and then call back into the unmanaged host to perform the actual switch. This goes into the API that we looked at in Article 7 – we simply switch out the current task, and switch in the new one that we passed in.

Finally we call OnFiberSwitchIn. Again this is another place where we have both a top-half before the switch, and a bottom-half after we’ve switched away and switched back. When we do the switch in if it’s the 1^st time a task has been scheduled we’ll end up back at RealFiberStart. If this task has already switched out once, we’ll end up at the curFiber.OnFiberSwitchIn line, but we’ll be on a different fiber (we’ll be on curFiber). In either case we’ll set the state on the previous fiber so that it’ll be schedulable again, and we’ll check the newly switched in fiber to see if it should be aborted.

And that’s how we switch fibers. You first create a fiber, and then you call SwitchTo on the newly created fiber. We largely just do some book keeping, and then call directly into the host to do the switch. It’s that simple.

That takes us through nearly all the basic mechanisms of the fiber mode host. In the next article I’m going to discuss how the Fiber class exposes Abort and RudeAbort APIs. A typical host wouldn’t expose these to managed code, but the CoopFiber sample has it’s reasons for doing so…

[9/16 8:00PM - Fixed grammer]

Cooperative Fiber Mode Sample - Day 8

DinoV — Thu, 09 Sep 2004 18:25:00 GMT

It seems like a good time to take a breather and look at what we have going on so far.

First, we’ve started the runtime. We’ve handed our IHostControl off to the runtime. The runtime has called back to our IHostControl and gotten a couple of managers. Those are our task manager and our synchronization manager. Whenever the runtime needs to create a thread it’s called us back, and we’ve created a brand new thread. Sure, we’ve converted it into fibers, but we’ve done no real fiber switching.

Whenever the runtime needed a manual or auto event we’ve given it to it via the synchronization APIs. When it needed to block on it, it called us, and we blocked on it via IHostAutoEvent or IHostManualEvent. If another thread alerted the thread blocked on the event, the runtime called us via the IHostTask APIs, and we queued and APC to it.

If the runtime needed to enter a critical section, it called us, and we blocked or allowed it to enter via the IHostCrst APIs.

We’ve set up everything necessary to replace the CLR’s threading model, but for the most part we’ve merely delegated to the OS APIs. Sure, there were minor differences here and there… But for every task the CLR asks for we create 1 physical thread. And sure every one of those physical threads has already been converted to a fiber, but we never switch those fibers out.

Starting with the next article that’ll start to change.

Cooperative Fiber Mode Sample - Day 7

DinoV — Tue, 07 Sep 2004 19:49:00 GMT

At this point we’ve covered nearly all the major components of the unmanaged host. The one remaining detail is the interface that’s used between the managed fiber mode implementation and the unmanaged host. This is all implemented in callbacks.cpp. We essentially expose an API for all the major operations we allow the fiber API to do. These include creating fibers, switching fibers in, aborting fibers, and exiting the current fiber.

The creation of a fiber differs from the CreateTask API we covered before in that we aren’t creating a new thread for this fiber. This fiber is newly created and won’t run until a user switches it in. Aborting fibers is exactly like aborting a thread, but a fiber will need to be switched in to be properly aborted.

Switching in fibers is interesting. Here you’ll find no “SwitchOut” API like the internal unmanaged SwitchOut method on CHostTask. This is because we cannot run managed code on a “switched out” task. It has to have some task to run on! Instead CoopFiber exposes one API for switching in a new task that also switches out the current task.

All of these methods are merely thin wrappers over the functionality we’ve already covered. Two interesting examples of the several functions include InternalCreateFiber and InternalSwitchIn.

First let’s look at InternalCreateFiber:

__declspec(dllexport) PVOID InternalCreateFiber(PVOID startAddr)

{

CHostTask *tmp = CHostTask::CreateTask();

if (tmp == NULL)

{

_ASSERTE(FALSE && "Out of memory in CreateTask!");

return NULL;

}

tmp->SetManagedStart(reinterpret_cast<LPTHREAD_START_ROUTINE>(startAddr));

tmp->AddRef();

tmp->SetFiberAddress(::CreateFiber(0,(LPFIBER_START_ROUTINE )CHostFiberProc,(PVOID)tmp));

return(tmp);

}

This function creates a new CHostTask, sets the start address (which is a delegate passed from managed code), and create a new fiber for the task. We return the task back to managed code which now holds the only reference to it.

The interesting thing to note is the management of the lifetime of the CHostTask. We have 1 reference to it from the managed code. As we’ll see later the managed code uses a new Whidbey feature called SafeHandle. This ensures that when the managed Fiber object is collected our InternalReleaseFiber method will be called.

Next let’s look at InternalSwitchIn:

__declspec(dllexport) void InternalSwitchIn(CHostTask *task)

{

CHostTask *curTask = CHostTask::GetCurrentTask();

_ASSERTE(curTask && task);

curTask->SwitchOut();

task->SwitchIn();

}

Here we get the current task, switch it out, and switch in the task passed in. Again, we have another simple thin wrapper over the APIs we’ve already seen. All of the other callbacks are thin wrapper as well.

So we’ve now covered nearly all the main principals of the unmanaged code. Soon we can start to discuss what the host is going to expose to the managed code author!

Cooperative Fiber Mode Sample - Day 6

DinoV — Fri, 03 Sep 2004 22:04:00 GMT

The synchronization primitives are handled off to the runtime by the IHostSyncManager interface. We’ve already provided this to the runtime through our GetHostManager callback on IHostControl. Our IHostSyncManager is implemented on our IHostTaskManager and for the most part we just create objects and hand them off. For example CreateCrst looks like:

*ppCrst = (IHostCrst *)new CHostCriticalSection(this);

if(NULL == *ppCrst)

{

return(E_OUTOFMEMORY);

}

(*ppCrst)->AddRef();

And none of them are very different. Our SetCLRSyncManager does nothing. A more sophisticated host could use the ICLRSyncManager to help perform deadlock detection.

The CoopFiber implements 4 synchronization primitivies: Auto Events, Manual Events, Critical Sections, and a Semaphore. All of these with the exception of the critical section are just thin wrappers over the equivalent OS API. For example looking at CHostManualEvent::Wait:

DWORD result;

if(option & WAIT_ALERTABLE)

{

result = WaitForSingleObjectEx(m_hEvent, dwMilliseconds, true);

}

else

{

result = WaitForSingleObject(m_hEvent, dwMilliseconds);

}

switch(result)

{

case WAIT_OBJECT_0:

return(S_OK);

case WAIT_ABANDONED:

return(HOST_E_ABANDONED);

case WAIT_IO_COMPLETION:

CHostTask::GetCurrentTask()->FlagSet(TASK_FLAG_ALERTED, false);

return(HOST_E_INTERRUPTED);

case WAIT_TIMEOUT:

return(HOST_E_TIMEOUT);

default:

_ASSERTE(!"Shouldn't reach here");

return(E_FAIL);

}

We can see an implementation that is nearly identical to Join we saw last time. Both the auto event and semaphore implementations are nearly identical. More sophisticated hosts could perform deadlock detection below these events (for reader/writer locks and monitors built on top of the events), or they could choose to schedule other fibers on these threads. For this simple implementation we simply block the current thread.

The critical section is the only synchronization primitive which doesn’t simply wrap the OS API. This is because the critical section is owned by a specific thread (unlike the events and semaphore). Because of this the critical section must be aware of the fibers in addition to threads. This will prevent one fiber from acquiring the critical section, and having another fiber re-acquire on the same thread.

The essence of the critical section acquire lives in TryEnter, which Enter builds on:

if(m_holderTask == NULL)

{

CritSecHolder cs(&m_critSec);

// no one holds the critical section

if(m_holderTask == NULL && WaitForSingleObject(m_hEvent, 0) == WAIT_OBJECT_0)

{

// we've acquired the crit section

m_holderTask = curTask;

m_dwEnterCount = 1;

*pbSucceeded = TRUE;

return(S_OK);

}

else if(m_holderTask == curTask)

{

CritSecHolder cs(&m_critSec);

// we already hold the critical section

if(m_holderTask == curTask)

{

m_dwEnterCount++;

*pbSucceeded = TRUE;

return(S_OK);

}

return(S_OK);

There’s a couple of points to note. First, we use a critical section to protect our state. We don’t want to worry about other threads entering. Also we use an event to block the task if the critical section cannot be acquired. A more sophisticated fiber scheduler would want to re-schedule another fiber rather than block the current thread.

Those are the core synchronization primitives that we’re using in CoopFiber. You can see by limiting the scope of what CoopFiber does we were able to merely rely upon the OS APIs in most circumstances. Next time I’ll start discussing the managed / unmanaged fiber API interface.

Cooperative Fiber Mode Sample - Day 5

DinoV — Tue, 31 Aug 2004 20:05:00 GMT

Last time we successfully created a task and started it running. That’s an accomplishment, but there are a couple of details we should get out of the way before we start to dive deeper into the fiber mode implementation. Those are all on IHostTask and are Alert and Join. Once again everything else is trivial or non-important for CoopFiber’s implementation.

Last time we saw a peek at Alert. This was the m_hCurThread member variable that we set when a fiber was switched in. Our Alert implementation uses this:

if(FlagCheck(TASK_FLAG_RUNNING))

{

QueueUserAPC(&MyAPCProc, m_hCurThread, NULL);

}

FlagSet(TASK_FLAG_ALERTED,true);

return(S_OK);

Here we check if the current task is running, and if so we queue an APC to that task. The queued APC is just a simple do-nothing function to wake the task out of its blocking operation. Whether the task is running or not we set the alert bit.

One interesting aspect of this simple sample is that if the user doesn’t schedule the task the alert can never respond. A more complex host may choose to give priority to alerted tasks or schedule them immediately.

The next API to look at is the Join implementation:

HRESULT __stdcall CHostTask::Join(DWORD dwMilliseconds, DWORD option)

{

DWORD result;

if(option & WAIT_ALERTABLE)

{

result = WaitForSingleObjectEx(m_hTaskExitedEvent, dwMilliseconds, true);

}

else

{

result = WaitForSingleObject(m_hTaskExitedEvent, dwMilliseconds);

}

switch(result)

{

case WAIT_OBJECT_0:

return(S_OK);

case WAIT_TIMEOUT:

return(HOST_E_TIMEOUT);

case WAIT_IO_COMPLETION:

return(HOST_E_INTERRUPTED);

}

_ASSERTE(!"Shouldn't reach here");

return(E_FAIL);

}

Here we simply block the current task on an event that is set in our internal CHostTask::ExitTask API. We’ll do an alertable wait if requested, to which the APC queued in Alert will wake us up. Finally Join translates the result of WaitForSingleObject* into the appropriate host HRESULT.

We’ve mentioned ExitTask twice now (once in SwitchIn and here again) so now seems like an appropriate time to cover it. This internal API merely calls the ICLRTask::ExitTask callback, notifying the runtime the task has exited, and updates our internal bookkeeping:

if(m_pCallback!=NULL)

{

m_pCallback->ExitTask();

}

SetEvent(m_hTaskExitedEvent);

FlagSet(TASK_FLAG_EXITED,true);

FlagSet(TASK_FLAG_RUNNING,false);

The one interesting call worth noting here is that we set the event that allows our Joined tasks to wake up. A more complicated host would use Join as an opportunity to deschedule a fiber and would need a more sophisticated mechanism of handling exited tasks.

Well that wraps it up for this edition… There’s only one more piece of unmanaged code before we start getting into the managed world. Next time we’ll delve into the synchronization primitives.

Cooperative Fiber Mode Sample - Day 4

DinoV — Thu, 26 Aug 2004 18:56:00 GMT

Last time we left off with the CLR calling into the host to create a task. So far everything’s been very simple. For each interface we’ve only needed to implement a couple of methods to get the bulk of the work done. While I’ve certainly left out a couple of lines of code here and there, nearly every other API in the interface merely returns S_OK.

Now things start to get really interesting! The IHostTask interface has just a few functions which are exposed to the runtime. But there’s a lot of other functionality related to the task embedded in here.

We’ll start off at the natural place to start a task: Start. It’s pretty simple:

FlagSet(TASK_FLAG_NOTSTARTED,false);

_ASSERTE(m_fiberAddr == NULL);

m_fiberAddr = ::CreateFiber(0,(LPFIBER_START_ROUTINE )CHostFiberProc,(PVOID)this);

// create the new thread

::CreateThread(NULL,NULL,reinterpret_cast<LPTHREAD_START_ROUTINE>(::StartNewThread),this,NULL,NULL);

return(S_OK);

We create a fiber for the new task, and we create a new thread. This new thread starts in StartNewThread, defined in callbacks.cpp. It looks something like:

CHostTaskManager *myManager = CHostTask::GetManager();

CHostTask *curTask = static_cast<CHostTask*>(lpParameter);

LPVOID fiberAddr = ConvertThreadToFiber(NULL);

curTask->SwitchIn();

BOOL fResult = ConvertFiberToThread();

Here we simply convert the new thread over to fibers, and then switch in the fiber passed as the argument. This brings us back to our CHostTask implementation where we need to look at the SwitchIn logic. This is the most complicated piece of code we’ve encountered yet.

CHostTask *curTask = GetCurrentTask();

_ASSERTE(curTask != this);

TlsSetValue(CHostTask::CurTaskTlsIndex,this);

this->AddRef();

// Save our thread handle so we can queue APCs

if(!DuplicateHandle(GetCurrentProcess(),

GetCurrentThread(),

GetCurrentProcess(),

&m_hCurThread, 0 , FALSE,

DUPLICATE_SAME_ACCESS))

{

m_hCurThread = INVALID_HANDLE_VALUE;

_ASSERTE(!"Duplicate handle failed");

}

FlagSet(TASK_FLAG_RUNNING, true);

::SwitchToFiber(GetFiberAddress());

// when the fiber switches back we need to switch in our

// previous task.

if(curTask->m_pCallback!=NULL)

{

HRESULT hr = curTask->m_pCallback->SwitchIn(GetCurrentThread());

_ASSERTE(SUCCEEDED(hr));

}

if(curTask->FlagCheck(TASK_FLAG_EXITING))

{

_ASSERTE(curTask->GetSwitchingTo());

curTask->ExitTask();

curTask->GetSwitchingTo()->SwitchIn();

}

// release the ref for TLS from the previous thread

CloseHandle(m_hCurThread);

m_hCurThread = INVALID_HANDLE_VALUE;

Release();

SetThreadPriority(GetCurrentThread(), curTask->m_iPriority);

SetThreadLocale(curTask->m_lcid);

What’s going on here? We have a couple of things to worry about when switching tasks. We have the task that we’re switching to (this) and we have the task we’re switching from (curTask).

One of the issues we’re concerned with is the lifetime of the task. While it’s running we don’t want it cleaned up, so we hold a reference to it (in Thread Local Store). A more complicated host would probably have a pool of tasks rather than the simple TLS mechanism.

If we need to alert a task we’ll queue an Asynchronous Procedure Call (APC) to it. Therefore the next thing we do is save the current thread’s handle into this task. We’ll use this in IHostTask::Alert. Finally we set the running flag and switch over to the new task.

The interesting thing to note about this method is there are 2 halves to it. After we call SwitchToFiber we are running on a different fiber on a different stack. We’ll only return to the bottom half after someone has switched back to “curTask”. This is the task that we switched away from. When this happens it’s now the bottom half’s job to tell the runtime that “curTask” is once again running.

It’s possible when we get to the bottom half “curTask” was only switched in to exit. If so we’ll notify the runtime and immediately re-run the task we’ve been set to re-run. This is an implementation detail of CoopFiber to allow calling ExitTask on the managed fiber implementation.

We’re nearly done so we clean up the resources we allocated in the top half for “this”. It’s no longer running, so we don’t need a reference to it. Finally we restore the settings for the thread that were stored in the task. These would have been changed when we did the intital SwitchToFiber which either switched in a task that was at the bottom half of SwitchIn, or the top of CHostFiberProc (in callbacks.cpp).

Wow, so that’s how we start a task! We create a new thread, that thread gets converted over to fibers, and we switch in the newly created task (which has a fiber already associated with it). That’ll end up in CHostFiber proc which we’ll cover in a future edition.

There’s just one more detail to cap off the life time of a task, and that is our internal SwitchOut API. All it essentially does is set some state and notify the runtime of the switch out:

FlagSet(TASK_FLAG_RUNNING,false);

if(m_pCallback!=NULL)

{

HRESULT hr = m_pCallback->SwitchOut();

}

Next time we’ll go over the remaining APIs on IHostTask that we haven’t covered yet.

Cooperative Fiber Mode Sample - Day 3

DinoV — Mon, 23 Aug 2004 21:47:00 GMT

When I last left off we went over the host control. The host control hands off our task and synchronization managers. Now it’s time to take a look at the two host-implemented managers, starting with the task manager.

I’m going to skip over the minor details such as constructors, destructors, etc… and only focus in on the details of the APIs that communicate with the CLR. The APIs we care about the most are GetCurrentTask and CreateTask. A fiber mode host with it’s own scheduler would pay more attention to APIs like Sleep (where we merely call the OS API), SwitchToTask (which is a NOP in CoopFiber), and the other APIs. Because CoopFiber doesn’t have a scheduler we aren’t concerned with these APIs. So if we look at GetCurrentTask:

_ASSERTE(pTask);

CHostTask *curTask = CHostTask::GetCurrentTask(false);

if(curTask==NULL)

{

// 0x1E00 - value returned by GetCurrentFiber when not a fiber

if(GetCurrentFiber()==(PVOID)0x1E00)

{

curTask = CHostTask::CreateTask(ConvertThreadToFiber(NULL),TASK_FLAG_RUNNING);

}

else

{

curTask = CHostTask::CreateTask(GetCurrentFiber(),TASK_FLAG_RUNNING);

}

curTask->AddRef();

*pTask = (IHostTask *)curTask;

return(S_OK);

We simply check to see if the current task has been created. If it hasn’t we create a new task. Depending on whether or not we’re already running on a fiber (by some chance) we’ll re-use the fiber, otherwise we’ll create a new fiber. Here we choose to allow any random threads that enter into the CLR to be converted to fibers. A host could also deny these threads entrance by returning HOST_E_INVALIDOPERATION.

The other interesting API is CreateTask:

_ASSERTE(ppTask!=NULL);

_ASSERTE(pStartAddress);

CHostTask *tmp = CHostTask::CreateTask();

if (tmp == NULL)

{

_ASSERTE(FALSE && "Out of memory in CreateTask!");

return E_OUTOFMEMORY;

}

tmp->SetStart(pStartAddress, pParameter);

tmp->AddRef();

*ppTask = (IHostTask *)tmp;

return(S_OK);

This isn’t really doing anything too fancy. We’re just creating out internal task implementation which implements IHostTask. We’re handing that off to the runtime. Later the runtime will call Start on it and it’ll kick off the running of a new task. We’ll look at the IHostTask implementation next time.

Cooperative Fiber Mode Sample - Day 2

DinoV — Wed, 18 Aug 2004 17:07:00 GMT

In the last blog entry I went over how we start the runtime. Once it was loaded we were running managed code, but I glossed over the managers that were present and participating in running the system. Today we start off with CHostControl::GetHostManager. CHostControl is CoopFiber’s implementation of IHostControl, and GetHostManager is the only API we implement.

HRESULT __stdcall CHostControl::GetHostManager(

/* [in] */ REFIID riid,

/* [out] */ void **ppObject)

{

if(riid == IID_IHostTaskManager)

{

if(m_pTaskMan == NULL)

{

m_pTaskMan = new CHostTaskManager();

}

*ppObject = static_cast<IHostTaskManager*>(m_pTaskMan);

m_pTaskMan->AddRef();

return(S_OK);

}

else if(riid == IID_IHostSyncManager)

{

if(m_pTaskMan == NULL)

{

m_pTaskMan = new CHostTaskManager();

}

*ppObject = static_cast<IHostSyncManager*>(m_pTaskMan);

m_pTaskMan->AddRef();

return(S_OK);

}

return(E_NOINTERFACE);

}

What are we doing here? CHostControl has one task manager. That task manager actually implements both IHostTaskManager and IHostSyncManager. These are the minimal APIs you need to implement fiber mode of any sort. IHostTaskManager provides the mechanisms for creating tasks. IHostSyncManager provides the mechanisms for providing synchronization between those tasks.

At load time, the CLR calls the host-implemented IHostControl interface and asks for the managers that the CLR knows about. The host can respond by handing back an interface pointer or it can respond by returning E_NOINTERFACE. Virtually any combination of managers is supported. The one gotcha is your thread and synchronization must be compatible. The default synchronization implementation in the CLR is not fiber aware. That’s the reason that we implement both a task and synchronization manager for this fiber mode sample.

Here our GetHostManager implementation simply lazily creates the task manager for the first caller and hands it off to the runtime. If it’s a manager the host doesn’t know about we return E_NOINTERFACE.

The host control also provides a couple of other APIs that we’re not using here. The first is SetAppDomainManager. This is where the host is notified of the creation of an app domain. The host is passed both the ID of the newly created app domain and an IUnknown pointer for the app domain manager. Because CoopFiber doesn’t use an app domain manager we’ll never get any calls here. We simply return E_NOTIMPL.

The other API is GetDomainNeutralAssemblies. This is another API that CoopFiber doesn��t use because it doesn’t care whether assemblies are loaded domain neutral or not. Again, it simply returns E_NOTIMPL.

So that’s it for the host control. Stay tuned for the next entry when I’ll dig into our task manager. Things will start to get really interesting then!

Cooperative Fiber Mode Sample - Day 1

DinoV — Mon, 16 Aug 2004 15:50:00 GMT

Well it’s been a while since I’ve blogged… There’ve been a few distractions, starting with Beta 1, then vacation, and now things are back to normal. So it seems reasonable to blog about something that we’ve just shipped in Whidbey Beta 1: The cooperative fiber mode sample that’s been included in the SDK. You can get the freely downloadable SDK here. If you load up the documentation, go to the Contents, and select Samples->Application Samples->Cooperative Fiber Mode Application Sample you’ll be able to get to the code.

This sample shows how to write an extremely simple fiber mode host. But it does so with a twist. Instead of scheduling the tasks in a cooperative, automatic, and transparent fashion this sample exposes the concept of fibers to managed code . This allows the managed code author to use fibers as the unmanaged code author would. This results in an implementation that for the most part relies upon native threads. The only time fibers are actually used is when the user explicitly chooses to use them. This closely matches the experience you’d have programming with fibers in the unmanaged world. More sophisticated hosts would want to implement their own synchronization primitives that would schedule other tasks while blocking.

Over the next several blog entries I plan to give a walk through of the new fiber mode sample. During this blog I’ll start with loading the runtime and getting bootstrapped into managed code. But first let me give a brief warning. Fiber mode is complex and hard to get right. You probably don’t want to implement fiber mode into your application on a whim. Weigh your other options carefully before jumping into running in fiber mode.

Loading the runtime hasn’t changed in a significant fashion from v1.0 and v1.1. We start with a call that should be familiar to anyone who has written code to host the runtime before:

// load up the runtime

HRESULT hr = CorBindToRuntimeEx(

NULL, // version of the runtime to request

NULL, // flavor of the runtime to request

0, // runtime startup flags

CLSID_CLRRuntimeHost, // clsid of ICLRRuntimeHost

IID_ICLRRuntimeHost, // IID of ICLRRuntimeHost

(PVOID*)&pClrHost); // a pointer to our punk that we get

The only difference you may notice is that we’re asking for a different interface. Previously we asked for CLSID_CorRuntimeHost and IID_ICorRuntimeHost. In Whidbey we have a brand new interface that let you do much more.

Next, we have a new call:

hr = pClrHost->SetHostControl(static_cast<IHostControl *>(&hostControl));

This new command is handing off to the runtime our IHostControl interface. It’s not a required call for hosting the runtime, but it’s the mechanism through which we provide our threading managers (so it is required for fiber mode). One callback on this API is GetHostManager which when called by the runtime allows the host to provide a manager. The host managers provide threading, memory, assembly loading, or other low level functionality to the runtime. Throughout the next couple of articles I’ll be strictly focused on the threading managers.

After we hand off our host control we’re back to familiar territory again:

hr = pClrHost->Start();

Now the runtime has been started and we can start executing managed code. And the way we start doing this has changed in Whidbey. There are a few different mechanisms, and I’ll mention 2 of them. The first is the app domain manager. This allows a host to have an assembly loaded into every domain, including the default domain. Once this assembly is loaded the host can start running managed code directly from it. The other option is a sample call to execute an assembly passing it a string of arguments. This sample uses the 2^nd method as it’s simpler and sufficient for our purposes:

hr = pClrHost->ExecuteInDefaultAppDomain(

curDir, // directory to assembly

L"Microsoft.Samples.FiberBootstrap",// Type name to load

L"EntryPoint", // Method name to execute

bootstrapArgs, // Arguments to be passed in

&retVal); // return value of function

The executed function exists in a separate managed DLL (FiberBootstrap.dll). It simply parses the string and then calls AppDomain.ExecuteAssembly on the current domain. This allows the sample to run any managed assembly you pass to it. This EXE that gets loaded then can interact with the fiber mode APIs.

At this point we’ve loaded the runtime, loaded an assembly into the default domain and executed managed code. That’s really all there is to getting started. If you were a simpler host you wouldn’t even need the SetHostControl call! In the next article I’ll discuss what that SetHostControl call is setting up for us.

Testing Fiber Mode

DinoV — Wed, 26 May 2004 18:48:00 GMT

Testing Fiber Mode Fiber mode is one of the interesting new features we’ve done in hosting. Fiber support in .NET comes up as a common question too. I’d like to give an overview of what we’ve done to test fiber mode to ensure that you’ll get a good experience if you choose to use it – and however you choose to use it.

To test fiber mode we created a test harness (called HostDriver) which could host the CLR. HostDriver supports a wide number of options, but the one I’ll focus on today is the ability to plug-in a user-defined set of managers. Those managers include things like a task manager (IHostTaskManager), a synchronization manager (IHostSynchronizationManager), a threadpool manager (IHostThreadpoolManager), an I/O completion manager (IHostIoCompletion) and several others. These managers can be mixed and matched from multiple DLLs, or they can all reside in the same DLL. HostDriver merges them together and presents a unified host to the CLR.

Once I had this infrastructure built the next task was to create a set of managers to plug-in. The initial one is obvious: Create a task manager that is a thin wrapper over the Win32 APIs. This provides a nice, simple task manager that is easy to debug (this is important!) when things go wrong. Unfortunately it doesn’t do nearly a good enough job of exercising the hosting APIs. So once this one was up and running I moved onto implementing a fiber task manager to run in this environment. As you may imagine, that was a lot of fun (and certainly was challenging).

There were a few really great things about this test harness. It allowed us to get broad coverage across how the threading APIs are changed when hosted. It allowed us to get broad coverage across how the programmer uses the hosting APIs. Finally it allowed us to get broad coverage of the various features running in fiber mode.

The first tests were the threading tests running inside the hosted environment. Obviously the threading tests are some of the most interesting because fiber mode is primarily changing the threading model. This includes things like exercising the thread-pool, synchronization, starting threads, aborting threads, etc… Today we exercise a large amount of threading functionality in our automation test passes to ensure this doesn’t regress.

The second win was the ability to cover the matrix of mixing and matching various managers. Want to use just a memory manager? That works. How about a memory manager and a thread pool manager? That works too. How about I/O completion and synchronization? Absolutely! Again, these tests make it into automation to ensure we don’t regress in these areas.

Want to use a task manager that’s running in fiber mode but not a synchronization manager? Don’t do that – your locks won’t be aware of what threads they’re running on! This is a fact that’s easy to overlook when you’re first implementing a fiber mode task manager. Unfortunately the runtime cannot detect this (and therefore it cannot be tested) but it is something you’ll need to consider when using the new hosting interfaces in fiber mode. If you think about it this makes sense: The threading and synchronization APIs need to be aware of what the other one is doing to function correctly.

And the final win was the ability to get broad coverage across all the product features running in fiber mode. This came to life in the form of a tool called Hostify and HostDriver’s evil cousin HostDriverDll. Hostify provides a mechanism to alter the CLR’s shim to allow the execution of arbitrary EXEs in a hosted environment. This allowed us to modify a machine and then run a normal test pass that would automatically run in a fiber environment. We can quickly cover a large portion of our code base in Fiber mode with minimal effort allowing us to run large fiber mode test passes. Unfortunately this is a long test pass that can’t just be put into our daily automation like another test. But before major releases (eg, alphas, betas, RCs, full releases) we do a full test pass that ensures that there have been no regressions introduced.

So that’s the short version of how we’ve worked to ensure that fiber mode is a solid feature. We’ve strived to test both the essential APIs in depth and get broad coverage across the feature set of the product. The matrix of possibilities is intense in the hosting layer but this effort should make your experience with them more pleasant.

.NET Trivia

DinoV — Fri, 14 May 2004 04:07:00 GMT

Here’s a fun piece of .NET trivia involving thread aborts and exception handling. What does the following code do? And why does it do it?

using System;

using System.Threading;

class TATest

{

public static void Main(string []args)

{

try

{

Console.WriteLine("Aborting!");

Thread.CurrentThread.Abort();

}

finally

{

if((Thread.CurrentThread.ThreadState & ThreadState.AbortRequested)!=0)

{

Console.WriteLine("Aborted!");

Thread.ResetAbort();

}

Console.WriteLine(“Bye bye!“);

}

(In writing this I've discovered my fingers really prefer to type byte over bye... that t just seems so natural to come next).b

Inaugural Blog

DinoV — Thu, 06 May 2004 19:59:00 GMT

Welcome to my blog. Yes, that’s right; you’re reading YAIB (Yet another Inaugural Blog). So, who am I, and why should you care? My name is Robert “Dino” Viehland (as in everyone calls me Dino, except for people who knew me in high school or before. E.g. parents, old friends, etc… So this is the only time I’ll mention Robert). I’ve worked at Microsoft for nearly 3 years now and that entire time I’ve been on the CLR team as an SDE/T. If you’ve missed the other introductions an SDE/T stands for Software Design Engineer/Test. That essentially means that I spend my time writing tests or test tools to test the product, running those tests or tools over the product, and investigating why they failed. In particular I own testing a portion of the CLR hosting interfaces test a portion of the CLR hosting interfaces and do a large amount of directed reliability testing. On the hosting side of things that includes new Whidbey features like threading abstraction APIs (fiber mode, deadlock detection, etc…) and memory abstraction APIs. On the reliability side of things I work on primarily directed reliability testing like fault injection and leak detection. Over the future of my blog I hope to blog about those new features and the work we’ve done to allow the CLR to run in-process with Yukon. And hopefully there’ll be some random anecdotes and other topics along the way. So once again, welcome to my blog!