Merge pull request #1 from jhickson/master

Merge code from personal repo

Author: Jos Hickson

.gitignore

@@ -0,0 +1,28 @@
+# Ignore everything
+*
+
+# Don't ignore directories, so we can recurse into them
+!*/
+
+# Except
+!.gitattributes
+!.gitignore
+!.gitconfig
+!*.cs
+!*.csproj
+!*.DotSettings
+!*.sln
+!*.json
+!*.md
+!*.snk
+!*.bat
+!*.sh
+!*.yml
+!*.ps1
+
+bin/
+obj/
+/.vs/
+/.vscode/
+Version.targets
+travis.props

.travis.yml

@@ -0,0 +1,24 @@
+language: csharp
+
+sudo: required
+
+os: linux
+
+dist: trusty
+
+branches:
+  except:
+  - /^[0-9]/
+
+dotnet: 1.0.1
+
+mono: none
+  
+script:
+  - (git fetch --unshallow 2>/dev/null || echo "Already full repo.")
+  - ./build.sh
+
+notifications:
+  on_success: always
+  on_failure: always
+  on_start: always

CONTRIBUTING.md

@@ -0,0 +1,42 @@
+# How to contribute
+
+One of the easiest ways to contribute is to participate in discussions and discuss issues. You can also contribute by submitting pull requests with code changes.
+
+## Filing issues
+The best way to get your bug fixed is to be as detailed as you can be about the problem.
+Providing a minimal project with steps to reproduce the problem is ideal.
+Here are questions you can answer before you file a bug to make sure you're not missing any important information.
+
+1. Did you include the snippet of broken code in the issue?
+2. What are the *EXACT* steps to reproduce this problem?
+3. What package versions are you using (you can see these in the `project.json` file)?
+4. What operating system are you using?
+
+GitHub supports [markdown](https://help.github.com/articles/github-flavored-markdown/), so when filing bugs make sure you check the formatting before clicking submit.
+
+## Contributing code and content
+Make sure you can build the code and run the tests. Familiarize yourself with the project workflow and our coding conventions. If you don't know what a pull request is read this article: https://help.github.com/articles/using-pull-requests.
+
+Before submitting a feature or substantial code contribution please discuss it with the team and ensure it follows the product roadmap. You might also read these two blog posts on contributing code: [Open Source Contribution Etiquette](http://tirania.org/blog/archive/2010/Dec-31.html) by Miguel de Icaza and [Don't "Push" Your Pull Requests](https://www.igvita.com/2011/12/19/dont-push-your-pull-requests/) by Ilya Grigorik. Note that all code submissions will be rigorously reviewed and tested by the Winton team prior to merging.
+
+Here's a few things you should always do when making changes to the code base:
+
+**Engineering guidelines**
+
+Please follow the existing coding style used in this project.
+
+**Commit/Pull Request Format**
+
+```
+Summary of the changes (Less than 80 chars)
+ - Detail 1
+ - Detail 2
+
+Addresses #bugnumber (in this specific format)
+```
+
+**Tests**
+
+-  Tests need to be provided for every bug/feature that is completed.
+-  If there is a scenario that is far too hard to test there does not need to be a test for it.
+  - "Too hard" is determined by the team as a whole.

README.md

@@ -1,2 +1,66 @@
 # Winton.Extensions.Threading.Actor
-An implementation of an actor designed to integrate with C#'s async/await.
+
+A lightweight implementation of the actor pattern designed to integrate with C#'s `async`/`await` keywords.
+It is a richer version of the implementation outlined on [Winton's Tech Blog](https://tech.winton.com/blog/2017/03/a-tpl-actor-pattern).
+
+## Overview
+
+Actors are objects that maintain a queue of work items and process that queue sequentially on a dedicated thread of
+execution.
+External agents pass work to an actor via messages.
+If required, messages can be used by an actor to transmit results in response to these messages.
+All interaction with actors is asynchronous.
+This is implemented here by viewing an inbound message as a delegate and an outbound response message as
+a `Task` or `Task<T>`.
+
+An important motivation for using actors is to avoid the sharing of data between threads within a process and
+so avoid the pitfalls such as deadlocks of synchronising access to that data.
+Rather than share data, a single entity (the actor) which carries out all actions in series is
+given responsibility for maintaining that data.
+A program can then be built as a set of interacting actors.
+Here execution flow is well-defined in that the scope of a single thread of execution is bounded to
+a single actor instance rather than it being the case that a thread of execution can wander unbounded
+through application code.
+In effect a single thread has a particular responsibility and does not stray beyond that responsibility.
+
+This library provides an implementation of an actor that allows work to be enqueued and handled sequentially.
+The actor can be started and stopped - though not paused - and support exists for specifying work to be done at both
+those state changes.
+In addition, a scheduler is provided to allow for the periodic scheduling of work on an actor.
+
+## Documentation
+
+The usage and API of this library are best illustrated via examples.
+These can be found in the [USAGE](USAGE.md) file.
+
+## Supported platforms
+
+The following platforms are supported:
+
+- .NET Core
+- .NET 4.5.1
+
+## Installation
+
+The easiest way to install this library is to add a NuGet dependency on `Winton.Extensions.Threading.Actor` to your
+library. 
+
+## Building
+
+Currently version `1.0` of the [.NET Core build tools](https://docs.microsoft.com/en-us/dotnet/articles/core/tools/) is required to build the source code.
+To build from Visual Studio you'll need VS 2017.
+
+Assuming you have the .NET Core build tools installed, building the library from the command-line just involves:
+
+```
+dotnet restore
+dotnet build
+```
+
+The tests use [xUnit.net](https://xunit.github.io/).
+To run them from the command-line use:
+
+```
+dotnet test Winton.Extensions.Threading.Actor.Tests.Unit/Winton.Extensions.Threading.Actor.Tests.Unit.csproj
+
+```