Async on 7sharp9

Monster Zero - Revisited

7sharp9@mail.com (Dave Thomas) — Wed, 05 Jun 2013 00:00:00 +0000

This creature is capable of tremendous destruction due to it’s size, flight (with the creature’s wings also generating hurricane strength winds) and possesses several breath weapons (e.g., heat and energy).

What am I talking about here? Maybe it’s Monster Zero or King Ghidorah as it’s sometimes known. No it’s TPL Dataflow!

I node something (Bout You)

7sharp9@mail.com (Dave Thomas) — Sun, 05 May 2013 00:00:00 +0000

What is Edge.js?
#

Unless you live in a hole you have probably heard of node.js so I’ll not bother to explain what it is or what it does. An interesting project has come to light lately, namely Edge.js. The Edge.js project allows you to connect node.js with .Net.

iOS async revisited

7sharp9@mail.com (Dave Thomas) — Thu, 18 Apr 2013 00:00:00 +0000

In this post weare going to look as async again, but from the perspective of F#.

Xamarin Evolve 2013
#

I have been watching the Xamarin Evolve conference this week and it was good to see Miguel announce full support for F#. Those that follow me on twitter etc, will know that I have been doing F# for quite a while in MonoDevelop and Xamarin Studio. The new support currently entails some new project templates so that you can easily create epic new F# Apps without having to refer to my blog. While its sad that my content now falls into the archives its nice to get official support announced in such a grand fashion.

A little bit of iOS async

7sharp9@mail.com (Dave Thomas) — Tue, 16 Apr 2013 00:00:00 +0000

I was going to title this post as ‘Now for something completely different’ but felt that a little bit too Pythonesque, and when I thought about it a bit it isn’t really completely just slightly different, namely C# rather than my usual F# posts.

The Lurking Horror

7sharp9@mail.com (Dave Thomas) — Sun, 15 Jul 2012 00:00:00 +0000

Deep in the darkest depths lurks an ancient horror, when the time is right it will rise forth and leave you screaming for mercy and begging for forgiveness…

OK, I have a penchant for being over dramatic but in this post I am going to reveal some little known caveats in a well known and much revelled area of F#, agents aka the MailboxProcessor. Gasp!

Back to the Primitive II

7sharp9@mail.com (Dave Thomas) — Sun, 22 Apr 2012 00:00:00 +0000

In the last post I discussed an asynchronous version of the ManualResetEvent and as promised this time we will be looking at an asynchronous version of the AutoResetEvent. I’m using Stephen Toubs post as reference and we will be building a version that is functional in style that maps straight into asynchronous work flows without and conversion or adaptors.

Back to the Primitive

7sharp9@mail.com (Dave Thomas) — Thu, 12 Apr 2012 00:00:00 +0000

In this post we are going back to the primitive. No it’s not about the same named song by Soulfly, (which incidentally does contains F# notes) but a return to thread synchronisation primitives and their asynchronous counterparts.

We are going to be looking at an asynchronous version of the ManualResetEvent. This was recently covered by Stephen Toub on the pfx team blog. We will be taking a slightly different view on this as we will be using asynchronous workflows which will give us nice idiomatic usage within F#.

FSharp Dataflow agents III

7sharp9@mail.com (Dave Thomas) — Mon, 20 Feb 2012 00:00:00 +0000

This will be the last post on rebuilding the MailboxProcessor using TDF, here’s a quick discussion of the missing pieces…

First, lets start with the simple ones, these don’t really require much discussion.

DefaultTimeout
#

let mutable defaultTimeout = Timeout.Infinite

member x.DefaultTimeout
 with get() = defaultTimeout
 and set(value) = defaultTimeout <- value

This simply provides a mutable property using Timeout.Infinite as a default setting.

F# Dataflow Agents Part II

7sharp9@mail.com (Dave Thomas) — Mon, 30 Jan 2012 00:00:00 +0000

Right, no messing about this time, straight to the code.

Construction
#

This is pretty straight forward and I don’t want to detract from the important bits of this post, the only thing of note is the cancellationToken which is initialized to a default value using the defaultArg function if the optional parameter cancellationToken is not supplied. The TDF construct that we to use to perform most of the hard work is incomingMessages which is a BufferBlock<'Msg>.

F# Dataflow Agents Part I

7sharp9@mail.com (Dave Thomas) — Sun, 22 Jan 2012 00:00:00 +0000

This is going to be a new series on using TPL Dataflow with F#. First a little bit of history and background.

TPL Dataflows heritage and background
#

TPL Dataflow or (TDF) has been around for quite a while, it first surfaced more than a year ago as the successor to the Concurrency and Coordination Runtime (CCR) and with coming release of .Net 4.5 it will be part of the System.Threading.Tasks.Dataflow namespace. Elements of the now halted project Axum are also present within the design of TDF.

Fixing a hole...

7sharp9@mail.com (Dave Thomas) — Sun, 11 Dec 2011 00:00:00 +0000

Due to popular demand… well, I had a couple of requests anyway :-) Heres a post inspired by my recent encounters profiling some of the code in Fracture-IO. I have recently been profiling the code in fracture to remove any so called low hanging fruits. During this time I also noticed an increase in memory allocation. I remembered I had recently been experimenting in a branch using pipelets as a buffer between the send and receive stages in the Http Server, so I set up a simple test to see if pipelets were contributing to the memory allocation issues I was seeing. Here’s the simple iteration test code I used for the memory profiling:

Agent based scheduling

7sharp9@mail.com (Dave Thomas) — Sun, 03 Jul 2011 00:00:00 +0000

One of the areas that I am very interested in is agents and I have been doing quite a lot of work in this area lately.

Agents can be used for a multitude of different purposes ranging from: isolated message passing, object caching, finite state machines, web crawling, and even reactive user interfaces. One of the ideas that I have been looking into lately is agent based scheduling.

Agents and ObjectPools

7sharp9@mail.com (Dave Thomas) — Sun, 05 Jun 2011 00:00:00 +0000

Everyone knows F# agents are cool right? Well here’s yet another example of how versatile they can be…

There was a series of posts last April by Stephen Toub from the pfxteam at Microsoft. I was reading through some of the posts again the other day and thought some of the ideas presented there would make interesting projects in F# to demonstrate the flexibility and succinctness of the language. I thought the ObjectPool example would make an interesting project in F# using agents aka MailboxProcessors. An ObjectPool is basically a pool of objects that have been pre-created so that you can grab one and use it, and then place it back in the pool when you’re finished. They are useful in situations where the cost of creating object from scratch is very high or you want to cut down on allocations in the garbage collector.

Pipeline processing 3

7sharp9@mail.com (Dave Thomas) — Mon, 04 Apr 2011 00:00:00 +0000

Ok so I have been offline for a while now, what with starting a new financial contract in London and not having any broadband access for a while. I have been working on something, honest!

Since the last post I have been reflecting on the pipeline design and it had a distinct object orientated feel to it that I wasnt happy with, so I have amended the structure of the code and come up with the following which simplifies in some areas and expands in others…

Pipeline processing 2

7sharp9@mail.com (Dave Thomas) — Sun, 13 Feb 2011 00:00:00 +0000

Welcome to pipeline processing part 2.
#

I feel I need to backtrack slightly from the previous post, having worked with pipelines for quite some time I have the advantage of knowing all of the details that may be alluded to in these articles without being effected by any omissions I may make, obviously you guys aren’t in that position, so I’m going to try and rectify that a bit now. If you have any queries then please leave a comment and I will try to address them in further articles. Pipelines are a simple concept but in practice there can be some caveats and things to bear in mind, sometime the whole mindset of development team can be against them unless they can see the bigger picture…

Pipeline processing 1

7sharp9@mail.com (Dave Thomas) — Tue, 01 Feb 2011 00:00:00 +0000

Welcome to new series of articles on pipeline processing.
#

First up, what’s a pipeline? Well according to Wikipedia:

A pipeline is a set of data processing elements connected in series, so that the output of one element is the input of the next one. The elements of a pipeline are often executed in parallel or in time-sliced fashion; in that case, some amount of buffer storage is often inserted between elements.

Sockets and Bockets 4

7sharp9@mail.com (Dave Thomas) — Fri, 28 Jan 2011 00:00:00 +0000

Welcome to part 4
#

If you were looking forward to some exciting new F# code this time your going to be disappointed, however if you are like me and like looking at graphs and stats and digging in deeper into the code then your going to enjoy this, lets get started…

Sockets and Bockets 3

7sharp9@mail.com (Dave Thomas) — Thu, 20 Jan 2011 00:00:00 +0000

Welcome to part three!
#

As promised heres a description of the inner workings. I’m sick to death of typing SocketAsyncEventArgs so from now on I will refer to it as SAEA.

Sockets and Bockets 2

7sharp9@mail.com (Dave Thomas) — Fri, 14 Jan 2011 00:00:00 +0000

Welcome to part two
#

Lets jump in at the deep end and take a look at some code…

When you look at the method syntax for the xxxAsync methods you will notice they return a boolean value that indicates if the method completed synchronously, this means that you have to check the return value every time you use one of the methods and invoke the callback yourself if it completes synchronously. In practice this hardly ever happens, and normally only on a send operation. But as it is a possibility we will add module with a some extension methods in to help us out, this will make the code more readable and avoid unnecessary duplication.

Sockets and Bockets 1

7sharp9@mail.com (Dave Thomas) — Thu, 13 Jan 2011 00:00:00 +0000

Welcome to part 1
#

A while back I read an interesting article by Brian McNamara f-async-on-the-server-side which describes C# and F# versions of a simple asynchronous socket server, one of the driving forces behind the article was how F# can wrap the traditional asynchronous model with Asynchronous Workflows, this produces nice clean simple code compared to the C# version which uses lambda expressions, the code looks quite ugly in this style! However thats not the end of the story, a lot of memory fragmentation can occur using the APM model when there is a high throughput, so I thought I would see if I could take this a step further…