Lately I had a chance to use the Bloomberg API to build a price capture service. In the context of finance the Bloomberg API -when run on a PC where the Bloomberg terminal is installed- allows you to read prices and rates for financial instruments. The “Bloomberg terminal” is an expensive piece of software that looks like nothing you’ve seen before unless you are old enough to have used the French Minitel. It comes with a funny-looking keyboard and a Mission Impossible-style fingerprint authentication system.
The API is straightforward and fully asynchronous. When opening a session you specify a single delegate that processes all notifications received from Bloomberg.
Bloomberg provides several services, some for real-time market data, others for reference static information, another for historical data… When you start a session, Bloomberg sends you a SESSION_STATUS message confirming the session is up. If you open a service you get SERVICE_STATUS messages . If you start subscribing to an instrument’s updates Bloomberg sends SUBSCRIPTION_DATA messages with the price updates as well as SUBSCRIPTION_STATUS messages containing subscription errors if something went wrong.
When writing such a client you find yourself waiting for a message before taking action. For instance you wait for a service to open before subscribing with instruments, you wait for subscription updates to arrive in order to save them to memory…
If you take action following the reception of a message, you run this action in the same call stack as the delegate you passed to the API. Is that a problem? Yes it can be: if your action takes too long, you slow down the Bloomberg thread consuming the messages and the system starts sending you ‘Slow Consumer’ warning admin messages.
So in the end you have to do things such as:
- redirect execution from a worker thread to the main thread (to avoid blocking the consumer thread)
- fire off a timer at regular intervals to display stats,
- schedule tasks at a set time (to schedule snapshots for instance)
- wait for several tasks to complete before starting a new one
Of course you could do all this using threads/handles/message loops, or the BackgroundWorker pattern which I used a lot when building windows UIs but it’s just not practical. So I started looking up MSDN to get familiar with the latest tools that make async programming easier (in .NET 4.0) with BeginInvoke / EndInvoke, thread pooling, the TPL…
@smwhit told me “Stop being such a C++ tard and take a look at Reactive Extensions”
Indeed RX is spot-on for this. One of the very very nice things with Reactive Extensions is that you can parameterize the scheduler. For each delegate you register you simply set a parameter to decide whether you want the code to run on a new thread, a thread pool, a dispatcher, an event pool or on the current thread the next time it’s available. You can even replace the scheduler with a TestScheduler, which makes unit-testing concurrent code possible.
Resources:
