Thrift is a software framework for scalable cross-language services development. It combines a software stack with a code generation engine to build services that work efficiently and seamlessly between C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk, and OCaml. http://thrift.apache.org/
There are two reasons for this post:
- to float some ideas for C#changes to the Thrift development community.
- to remind myself in the future what I need to do to download, modify and build the Windows Thrift compiler, and
The idea is to maintain backwards compatibility, whilst at the same time generating Silverlight (and consequently Windows Phone 7) compatible proxies.
Downloading and building the thrift compiler
To try out these changes on Windows, first install the latest version of Cygwin from http://cygwin.com/, then install the various packages as described here: http://wiki.apache.org/thrift/ThriftInstallationWin32
You’ll also need to install Subversion.
Next pop open the Cygwin shell, and fetch the latest source, as described here: http://thrift.apache.org/download/
Finally, build the source you downloaded, again as described here:
In my environment I build using:
And then I run the new thrift compiler:
Code Generator changes
The code generator (t_cpp_generator.cpp) changes involve generating two additional methods for each “standard” method: a Begin_… method and an End_… method.
Whereas previously there might just have been a method such as this:
Now, two additional methods get generated:
The two methods allow for the asynchronous invocation of methods, using the standard .NET asynchronous invocation pattern.
In addition, the generated standard method (“getSyncState”) method is modified when building for Silverlight, to make use of the Begin… and End… methods:
As you can see, when not running Silverlight the standard code path is invoked, but when running Silverlight the asynchronous methods are invoked (the End… method blocks the current thread until the Begin… method completes). This is not something you should be doing on the UI thread.
The generated Begin… and End… methods are pretty thin:
Note the call to EndFlush above – this is one of the changes made to the runtime. The other is invoked by the generated send_getSyncState method:
The generated recv_getSyncState() has not changed.
The changes in the generated code boil down to asynchronous invocations at the transport layer (BeginFlush and EndFlush).
There are also changes to #ifdef out the Serializable attribute for generated structs, since this is not supported by Silverlight.
There are minor tweaks required to THashSet, TProtocol and TBinaryProtocol because Silverlight does not support the full .NET framework API.
The main change is to TTransport.cs to introduce the BeginFlush and EndFlush methods shown above, and then to THttpClient.cs to actually implement these methods.
The existing Flush method is #ifdefed out when building using Silverlight, because it makes synchronous calls which are not supported by Silverlight.
Instead, the BeginFlush builds a request and then invokes the HttpWebRequest.BeginGetRequestStream method, passing a local GetRequestStreamCallback method as the callback.
The GetRequestStreamCallback method is invoked once the runtime has the request stream. It then writes out the data and invokes the HttpWebRequest.BeginGetResponse method, passing a local GetResponseCallback method as callback.
The GetResponseCallback notifies the original caller (in the generated code) that the request has now completed.
The EndFlush method waits for the corresponding BeginFlush method to complete, and if there was an exception thrown at any point, it raises the corresponding exception.