[WIP, RFC FS-1072] task and state machine support #6634

dsyme · 2019-04-24T18:45:31Z

[ Closed in favour of #6811 from a feature branch ]

This inserts a heavily modified (but semantically almost completely compatible) version of TaskBuilder.fs into FSharp.Core and adds a general state machine compilation mechanism for F# computation expressions.

Overview

The primary intention is to add quality support for task { ... } to F#. This means

library support for Task task { ... }
state machine compilation for computation expressions
support for using task-like tasks (value tasks etc.)
support for configurable tasks (half done)
support for defining value tasks
tests for all of these (half done)
proper debug support (stack, breakpoints, stepping) equivalent to C# (ok but needs testing)

We won't add the support until all of the above are done. We are starting with TaskBuilder.fs as a reference library implementation to help define semantics.

The mechanism we use to do this is to first add general support for "generated state machines" in F#.

Technical Note: Specifying generated state machines

From a high level, state machines are lovely to implement inefficiently in a functional language e.g. using continuations or F# async { ... } or TaskBuilder.fs task { ... }. These tend to allocate continuations and other values like crazy. Thus their efficient implementation (with low or zero allocation rates) means generating C-like constructs - label, goto, jumptables and and other such things.

It is hard to recover a low-allocation implementation from a functional/continuation/... implementation directly - but we can if we add enough compiler support for generating exactly the right code. Generation of efficient state machines from needs compiler support. For example both C# and F# support state machine compilation of C# iterator methods and F# seq { .... } expressions.

The magic heart of a typical generated state machine is a MoveNext or Step function that takes an integer program counter (pc) and jumps to a target:

      member __.MoveNext() = 
            match (pc) with
               | 1 -> goto L1 
               | 2 -> goto L2 
               | _ -> goto L0

            L0: ...
                ... this code can return, first setting "pc <- L1"...

            L1: ...
                ... this code can return, e.g. first setting "pc <- L2"...

            L2: ...

This is roughly what compiled seq { ... } code looks like in F# today and what compiled async/await code looks like in C#, at a very high level.

Note you can't write this kind of code directly in F# - there is no goto and the goto often jump directly into code resuming from the last step of the state machine.

In this mechanism we allow the specification of new varieties of generated state machines in library code, normally as part of the implementation of a computation-expression builder. (Note this is an extremely subtle mechanism and its validity is not yet checked by the compiler - "caveat emptor, here be dragons").

To help define generated state machines we use some primitives, currently

module Microsoft.FSharp.Core.CompilerServices.CodeGenHelpers
        val __jumptable : int -> (unit -> 'T) -> 'T
        val __stateMachine : 'T -> 'T
        val __newEntryPoint: unit -> int
        val __machine<'T> : 'T
        val __entryPoint: int -> unit
        val __return : 'T -> 'T

plus some special magic value names such __expand_XYZ and the very obscure __machine_step$cont.

A generated state machine expression is any expression of the form

    let inline makeStateMachine __expand_code = 
        (__stateMachine
            { new SomeBaseType() with 
                member __.SomeOverride(pc) =
                     __jumptable pc __expand_code }).SomeMethod()

Here SomeOverride will be compiled as a multi-entry method where the entry point is determined by pc using a jumptable at the start of the method.

Important The content of a generated state machine is specified by __expand_code which must be fully inlined code - that is, fully inlined to reveal the full implementation of the state machine. You can think of everything beginning with __expand_ABC as a macro where macro expansion is implemented by F# inlining.

For example, __expand_code could be a call to :

    makeStateMachine (bindTask task (fun res -> returnTask (res + 1))

where bindTask is inlined:

    let inline bindTask (task : Task<'TResult1>) (__expand_continuation : 'TResult1 -> TaskStep<'TResult2>) =
        let CONT = __newEntryPoint()
        let awaiter = task.GetAwaiter()
        if awaiter.IsCompleted then 
            __entryPoint CONT
            __expand_continuation (awaiter.GetResult())
        else
            __machine<TaskStateMachine>.Await (awaiter, CONT)
            __return false

and returnTask is inlined:

    let inline returnTask (x: 'T)  =
        __machine<TaskStateMachine>.Current <- x
        true

This shows the use of some of the other constructs in state machine specification - you can see

the compile-time creation of an entry point using __newEntryPoint()
the compile-time specification of the target of that entry point using __entryPoint
the compulsory macro expansion of the continuation using __expand_continuation
a self-reference to the state machine being run (using the this pointer) via __machine
an early exit from the state machine stepping function using __return

The constructs that can be used in the (inlined, expanded) state machine code is limited and in some cases (e.g. try/with blocks and while loops) extremely subtle. It is easy to create incorrect and invalid code using this mechanism.

For full details of current status see the implementation in the PR, details may have changed from the above.

When specifying state machines, it is common to return a typed "dummy" struct such as TaskStep<'T> from each call to the Step function where T represents the result of the task. This is sort of a phantom type.

Example: `sync { ... }`

As a micro "no-op" example of defining a builder which gets compiled using state machines, we can define sync { ... } which is for entirely synchronous computation with no special semantics.

Implementation: https://github.com/dsyme/visualfsharp/blob/tasks/tests/fsharp/core/state-machines/sync.fs

Examples of use:

let t1 y = 
    sync {
       printfn "in t1"
       let x = 4 + 5 + y
       return x
    }

let t2 y = 
    sync {
       printfn "in t2"
       let! x = t1 y
       return x + y
    }

printfn "t2 6 = %d" (t2 6)

Code performance will be approximately the same as normal F# code except for one allocation for each execution of each sync { .. } as we allocate the "SyncMachine". In later work we may be able to remove this.

Example: `task { ... }`

See the implementation in tasks.fs. There is complication due to the need to bind to task-pattern tasks and asyncs.

Example: `taskSeq { ... }`

This is for state machine compilation of computation expressions that generate IAsyncEnumerable<'T> values. This is a headline C# 8.0 feature and a very large feature for C#. It appears to mostly drop out as library code once general-purpose state machine support is available.

See the example in taskSeq.fs. Not everything is implemented yet but the basics work.

Example `seq2 { ... }`

See https://github.com/dsyme/visualfsharp/blob/tasks/tests/fsharp/core/state-machines/seq2.fs

This is an example showing how to do state machine compilation for seq2 { ... } expressions, akin to seq { ... } expressions, for which we bake-in state machine compilation into the F# compiler today. Caveats:

It doesn't cover tailcalls for recursive sequence generation
I haven't checked the disposal logic, though I think it's broadly correct
No perf testing done (it may be better, may be worse)
https://github.com/microsoft/visualfsharp/pull/6634/files#diff-4837d60671e85e130108370a6a8c0597R169

I think it's possible this version actually gives better stack traces than the current sequence expression support in the F# compiler.

This is essentially trimming the task support out of taskSeq { ... } .

Examples `list { ... }`, `array { ... }`

See https://github.com/dsyme/visualfsharp/blob/tasks/tests/fsharp/core/state-machines/list.fs

This example defines list { .. }, array { .. } and rsarray { .. } for collections, where the computations generate directly into a ResizeArray (System.Collections.Generic.List<'T>).

F#'s existing [ .. ] and [| ... |] and seq { .. } |> Seq.toResizeArray all use an intermediate IEnumerable which is then iterated to populate a ResizeArray and then converted to the final immutable collection. In contrast, generating directly into a ResizeArray is potentially more efficient (and for list { ... } further perf improvements are possible if we put this in FSharp.Core and use the mutate-tail-cons-cell trick to generate the list directly). This technique has been known for a while and can give faster collection generation but it has not been possible to get good code generation for the expressions in many cases. Note these aren't really "state machines" because there are no resumption points - there is just an implicit collection we are yielding into in otherwise synchronous code.

Using a directly-generating list { ... } seems to give a significant speedup over [ ... ] in the example I just tried, included in the code.

PERF: list { ... } : 497
PERF: [ ... ] : 748

Technical Note: Expected allocation profile for `task { ... }`

The allocation performance of the current approach should be:

one allocation of TaskStateMachine per task { ... }
one allocation of Task per task { ... }
one or two allocations on each let! or do! bind in a task { .. } - I'm not quite sure how many (we may be able to remove these when binding to another task produced by task { ... }, though I'm not sure).
there is an additional boxing allocation when a bind returns a value type - we can remove this later
one allocation on each let mutable used inside the task - these currently get turned into ref cells through * [x] the autobox transformation when let mutable is used in a task

More improvements are needed - see discussion below. We should compare with TaskBuilder.fs, Ply and C#.

Performance Status

Systematic perf testing of task { ... } is required.

Some benchmarks are at tests\fsharp\perf\tasks in the PR. Please help improve this.

Currently compile and run with:

msbuild tests\fsharp\perf\tasks\FS\TaskPerf.fsproj /p:Configuration=Release
dotnet artifacts\bin\TaskPerf\Release\netcoreapp2.1\TaskPerf.dll

The build/run cycle is a bit irritating as BenchmarkDotNet seems to run the "FSharpAsync" slow benchmarks around 100 times. Please help fix that.

Here are results at last run:

BenchmarkDotNet=v0.11.5, OS=Windows 10.0.18362
Intel Core i7-8750H CPU 2.20GHz (Coffee Lake), 1 CPU, 12 logical and 6 physical cores
.NET Core SDK=2.2.203
  [Host]     : .NET Core 2.1.9 (CoreCLR 4.6.27414.06, CoreFX 4.6.27415.01), 64bit RyuJIT DEBUG
  DefaultJob : .NET Core 2.1.9 (CoreCLR 4.6.27414.06, CoreFX 4.6.27415.01), 64bit RyuJIT

Method	Mean	Error	StdDev	Median	Ratio	RatioSD	Gen 0	Gen 1	Gen 2	Allocated
ManyWriteFile_CSharpAsync	18.19 ms	0.6308 ms	1.8499 ms	17.49 ms	1.00	0.00	406.2500	-	-	1.09 KB
ManyWriteFile_Task	16.66 ms	0.3535 ms	0.9062 ms	16.46 ms	0.92	0.09	406.2500	-	-	1.02 KB
ManyWriteFile_TaskBuilder	20.79 ms	0.4120 ms	1.0411 ms	20.83 ms	1.16	0.11	1125.0000	-	-	1.75 KB
ManyWriteFile_FSharpAsync	32.59 ms	0.6645 ms	1.9489 ms	32.80 ms	1.81	0.18	1750.0000	-	-	3.46 KB

Method	Mean	Error	StdDev	Median	Ratio	RatioSD	Gen 0	Gen 1	Gen 2	Allocated
SyncBinds_CSharpAsync	94.21 ms	1.942 ms	4.872 ms	92.28 ms	1.00	0.00	167833.3333	-	-	755.31 MB
SyncBinds_Task	120.77 ms	1.322 ms	1.104 ms	120.72 ms	1.26	0.09	167800.0000	-	-	755.31 MB
SyncBinds_TaskBuilder	160.14 ms	2.100 ms	1.964 ms	160.30 ms	1.66	0.11	256000.0000	-	-	1152.04 MB
SyncBinds_FSharpAsync	864.69 ms	3.520 ms	2.748 ms	865.17 ms	9.07	0.55	596000.0000	-	-	2685.55 MB

Method	Mean	Error	StdDev	Ratio	RatioSD	Gen 0	Gen 1	Gen 2	Allocated
AsyncBinds_CSharpAsync	121.53 ms	2.416 ms	3.901 ms	1.00	0.00	1000.0000	-	-	1.87 MB
AsyncBinds_Task	94.16 ms	1.820 ms	2.235 ms	0.77	0.03	1200.0000	-	-	2.33 MB
AsyncBinds_TaskBuilder	123.48 ms	2.234 ms	2.090 ms	1.01	0.04	3600.0000	-	-	4.96 MB

Method	Mean	Error	StdDev	Ratio	RatioSD	Gen 0	Gen 1	Gen 2	Allocated
SingleSyncTask_CSharpAsync	59.46 ms	0.3397 ms	0.3011 ms	1.00	0.00	-	-	-	-
SingleSyncTask_Task	63.98 ms	0.5184 ms	0.4849 ms	1.08	0.01	-	-	-	-
SingleSyncTask_TaskBuilder	94.40 ms	1.2734 ms	1.1911 ms	1.59	0.02	127000.0000	-	-	600000000 B
SingleSyncTask_FSharpAsync	1,160.43 ms	15.3916 ms	14.3973 ms	19.54	0.24	813000.0000	-	-	3840000000 B

…to proto

…o proto

dsyme · 2019-04-24T18:46:24Z

Note the library implementation is not big - just 300 lines. And it's pretty transparent what is happening apart from the advanced use of SRTP resolution

dsyme · 2019-04-24T19:11:21Z

The main problem here is adding the signature file, so large chunks are commented out.

cartermp · 2019-04-24T19:43:35Z

Link suggestion since the RFC isn't out yet: fsharp/fslang-suggestions#581

Arnavion · 2019-05-18T19:23:11Z

src/fsharp/FSharp.Core/tasks.fs

+        let __newEntryPoint() : int = failwith "__newEntryPoint should always be removed from compiled code"
+
+        [<MethodImpl(MethodImplOptions.NoInlining)>]
+        let __machine<'T> : 'T = failwith "__newEntryPoint should always be removed from compiled code"


Should the error message mention __machine instead of __newEntryPoint ?

…o tasks

dsyme · 2019-05-20T11:22:22Z

I have updated this PR removing one source of allocation, and updated the performance results

The allocation profile of the F# code is now identical to that of the C# baselines, except for AsyncBinds where there are some extra allocations (though fewer than TaskBuilder). However this doesn't hugely concern me as truly async binding almost always incurs other signficant allocations or delays. THe important thing is that there are now no extra allocations for synchronous binding.

The main thing now is to consider how to make the state machine feature sufficiently complete to allow its incorporation. From the examples I've worked through I'm convinced of the general utility of the mechanism, however there are some kinds of code that can't currently be compiled to state machines.

NinoFloris

Identified some last easy wins. If that doesn't pull the async profile in line with C# I'd have to pull out the decompiler/profiler to see what the statemachine codegen actually produces ;)

@dsyme end result looks great all things considering. Happy you were able to maintain quite some library level code. Thanks a lot for putting in the significant effort!

src/fsharp/FSharp.Core/tasks.fs

NinoFloris · 2019-05-20T11:41:09Z

src/fsharp/FSharp.Core/tasks.fs

+        // A using statement is just a try/finally with the finally block disposing if non-null.
+        builder.TryFinally(
+            (fun () -> __expand_body disp),
+            (fun () -> if not (isNull (box disp)) then disp.Dispose()))


Remove box by comparing via Object.ReferenceEquals

How is this done? My understanding is Object.ReferenceEquals(disp, null) will also box, unless the JIT elmiinates?

Jit eliminates due to generic specialization via the flexibile type sig.

I think we should double check either way

Definitely. Though it's quite a simple path, boxes are semantics changing so cannot be eliminated easily while ReferenceEquals gets aggressively inlined to what amounts to cmp disp, null; jne which for 'T = struct always is false = true. Branch elimination does the rest.

src/fsharp/FSharp.Core/tasks.fs

dsyme · 2019-05-20T21:54:49Z

@NinoFloris Thanks for the review. I've applied the changes and fixed a race condition.

Latest perf results are shown below F# is 26% slower for SyncBinds, and 23% faster than C# for AsyncBinds, at least on this test run. Allocations are zero for repeated SyncBindSingleTask, which is as hoped.

Method	Mean	Error	StdDev	Median	Ratio	RatioSD	Gen 0	Gen 1	Gen 2	Allocated
ManyWriteFile_CSharpAsync	18.19 ms	0.6308 ms	1.8499 ms	17.49 ms	1.00	0.00	406.2500	-	-	1.09 KB
ManyWriteFile_Task	16.66 ms	0.3535 ms	0.9062 ms	16.46 ms	0.92	0.09	406.2500	-	-	1.02 KB
ManyWriteFile_TaskBuilder	20.79 ms	0.4120 ms	1.0411 ms	20.83 ms	1.16	0.11	1125.0000	-	-	1.75 KB
ManyWriteFile_FSharpAsync	32.59 ms	0.6645 ms	1.9489 ms	32.80 ms	1.81	0.18	1750.0000	-	-	3.46 KB

Method	Mean	Error	StdDev	Median	Ratio	RatioSD	Gen 0	Gen 1	Gen 2	Allocated
SyncBinds_CSharpAsync	94.21 ms	1.942 ms	4.872 ms	92.28 ms	1.00	0.00	167833.3333	-	-	755.31 MB
SyncBinds_Task	120.77 ms	1.322 ms	1.104 ms	120.72 ms	1.26	0.09	167800.0000	-	-	755.31 MB
SyncBinds_TaskBuilder	160.14 ms	2.100 ms	1.964 ms	160.30 ms	1.66	0.11	256000.0000	-	-	1152.04 MB
SyncBinds_FSharpAsync	864.69 ms	3.520 ms	2.748 ms	865.17 ms	9.07	0.55	596000.0000	-	-	2685.55 MB

Method	Mean	Error	StdDev	Ratio	RatioSD	Gen 0	Gen 1	Gen 2	Allocated
AsyncBinds_CSharpAsync	121.53 ms	2.416 ms	3.901 ms	1.00	0.00	1000.0000	-	-	1.87 MB
AsyncBinds_Task	94.16 ms	1.820 ms	2.235 ms	0.77	0.03	1200.0000	-	-	2.33 MB
AsyncBinds_TaskBuilder	123.48 ms	2.234 ms	2.090 ms	1.01	0.04	3600.0000	-	-	4.96 MB

Method	Mean	Error	StdDev	Ratio	RatioSD	Gen 0	Gen 1	Gen 2	Allocated
SingleSyncTask_CSharpAsync	59.46 ms	0.3397 ms	0.3011 ms	1.00	0.00	-	-	-	-
SingleSyncTask_Task	63.98 ms	0.5184 ms	0.4849 ms	1.08	0.01	-	-	-	-
SingleSyncTask_TaskBuilder	94.40 ms	1.2734 ms	1.1911 ms	1.59	0.02	127000.0000	-	-	600000000 B
SingleSyncTask_FSharpAsync	1,160.43 ms	15.3916 ms	14.3973 ms	19.54	0.24	813000.0000	-	-	3840000000 B

NinoFloris · 2019-05-20T22:11:48Z

The asyncbinds result makes me suspicious though. Why is it deviating so much from both C# and Taskbuilder? (which are quite close to each other). Could it point to a behavioral difference?

Good to see a full MB of allocations, about 30%, shaved off by those changes, leaving just a tiny difference. Really have to see the IL for that last bit though, could be an FSharpRef or some other hiding in there.

dsyme · 2019-05-20T22:39:30Z

The asyncbinds result makes me suspicious though. Why is it deviating so much from both C# and Taskbuilder? (which are quite close to each other). Could it point to a behavioral difference?

I'll do a few more runs tomorrow, the results are a bit variable. I suspect the C# one just came in slow on that particular test run

Good to see a full MB of allocations, about 30%, shaved off by those changes, leaving just a tiny difference. Really have to see the IL for that last bit though, could be an FSharpRef or some other hiding in there.

I think the difference is just that the state machines are bigger, and when their state gets boxed this results in more allocated heap size. For example the F# state machine for AsyncBinds has this:

    .field public class [FSharp.Core]Microsoft.FSharp.Core.Unit Result
    .field public int32 ResumptionPoint
    .field public valuetype [System.Threading.Tasks]System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<class [FSharp.Core]Microsoft.FSharp.Core.Unit> MethodBuilder
    .field public valuetype [System.Runtime]System.Runtime.CompilerServices.YieldAwaitable/YieldAwaiter awaiter
    .field public valuetype [System.Runtime]System.Runtime.CompilerServices.YieldAwaitable/YieldAwaiter awaiter0
    .field public valuetype [System.Runtime]System.Runtime.CompilerServices.YieldAwaitable/YieldAwaiter awaiter1
    .field public valuetype [System.Runtime]System.Runtime.CompilerServices.YieldAwaitable/YieldAwaiter awaiter2
    .field public valuetype [System.Runtime]System.Runtime.CompilerServices.YieldAwaitable/YieldAwaiter awaiter3
    .field public valuetype [System.Runtime]System.Runtime.CompilerServices.YieldAwaitable/YieldAwaiter awaiter4
    .field public valuetype [System.Runtime]System.Runtime.CompilerServices.YieldAwaitable/YieldAwaiter awaiter5
    .field public valuetype [System.Runtime]System.Runtime.CompilerServices.YieldAwaitable/YieldAwaiter awaiter6
    .field public valuetype [System.Runtime]System.Runtime.CompilerServices.YieldAwaitable/YieldAwaiter awaiter7
    .field public valuetype [System.Runtime]System.Runtime.CompilerServices.YieldAwaitable/YieldAwaiter awaiter8

where the C# one has this:

    .field public int32 '<>1__state'
    .field public valuetype [System.Threading.Tasks]System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<int32> '<>t__builder'
    .field private valuetype [System.Runtime]System.Runtime.CompilerServices.YieldAwaitable/YieldAwaiter '<>u__1'

Looking at that I'm quite surprised the difference isn't actually great, but sizeof<MethodBuilder> is 12 and sizeof<System.Runtime.CompilerServices.YieldAwaitable.YieldAwaiter> is actually just one byte (I suppose a boolean), so I think that adds up.

I'm not immediately inclined to implement the state machine field sharing that C# has, partly because it can be a nightmare for debugging and hell if it goes wrong. Also we don't do that optimization for sequence expressions.

dsyme · 2019-05-20T22:51:02Z

The build is failing on Linux and Mac because the bootstrap compiler is not being used, see #6380

NinoFloris · 2019-05-20T23:48:31Z

I'll do a few more runs tomorrow, the results are a bit variable. I suspect the C# one just came in slow on that particular test run

Good to hear that, local machine runs are hard to get stable, thermal throttling and overactive background services cause night and day differences.

I'm not immediately inclined to implement the state machine field sharing that C# has, partly because it can be a nightmare for debugging and hell if it goes wrong. Also we don't do that optimization for sequence expressions.

Agreed, it's a bit more work during GC to track the extra references inside most of the awaiters (TaskAwaiter carries the ref of its Task) but it's much more straight forward like this. Always have the option to re-evaluate if somebody wants to build the next Kestrel in F# ;)

That does make me remember something else C# does, which is valuable to add.
Take TaskAwaiter<'T>, as it stores a reference to Task<'T> which can carry a user supplied 'state' object, continuations, and 'T which could be a huge object graph. The C# implementation sets the default value on the awaiter field once its done with it. Unrooting the Task reference and removing the possibility of pushing earlier allocations out to Gen 0/1 in longer running methods.

Also, and this applies more to C# — we don't have let! mutable — if you would receive a new unshared instance of 'T from your callee you'd expect nulling out its only visible binding allows the GC to clean it up. Keeping the Task alive in the state machine would prevent that.

forki · 2019-05-21T09:07:04Z

@dsyme I often have to use this:

 task { return myID }

would love to see some nice syntactic sugar and/or optimization that doesn't even create a task

ashtonkj · 2019-05-21T09:46:31Z

@dsyme I often have to use this:
 task { return myID }
would love to see some nice syntactic sugar and/or optimization that doesn't even create a task

Couldn't you just use Task.FromResult?

forki · 2019-05-21T09:56:07Z

right! Does that create an actual task as overhead?

ashtonkj · 2019-05-21T10:00:47Z

right! Does that create an actual task as overhead?

As far as I can see here (https://referencesource.microsoft.com/mscorlib/R/11a386e7d7cae64a.html) and here (https://docs.microsoft.com/en-us/dotnet/api/system.threading.tasks.task.fromresult?view=netframework-4.8#remarks) it creates a Task with the result immediately set and the status of RanToCompletion

forki · 2019-05-21T10:02:42Z

ok. question is: can we do similar in task { } for stuff that's basically already done?

ashtonkj · 2019-05-21T10:04:47Z

ok. question is: can we do similar in task { } for stuff that's basically already done?

I'm not sure I understand the question. Wouldn't return already do that?

forki · 2019-05-21T10:05:46Z

yeah maybe I'm stupid here. need to think about my question ...

benaadams · 2019-05-21T11:54:26Z

If it could be either; but usually is complete; then you can use ValueTask<'T> instead of Task<'T>.

dsyme · 2019-05-22T11:50:09Z

Closing in favour of #6811 from a feature branch

dsyme and others added 25 commits March 29, 2019 23:55

use proto on mac and linux

f4bd221

reduce diff

8a4baf3

reduce diff

0474a23

reduce diff

b96120e

reduce diff

cf9147b

reduce diff

286c336

reduce diff

7a6448e

Merge branch 'master' of https://github.com/Microsoft/visualfsharp in…

965d3b1

…to proto

Merge branch 'master' into proto

978414c

integrate master

95d94de

integrate master

a15ef59

fix build

aed6752

fix build

bb78e5f

Merge branch 'fix77' into proto

b88d23c

load right FSHarp.Build

1aa6a41

publish proto apps

058bdc9

revert test env changes

688850f

revert testing changes

c2c7213

Merge branch 'master' of http://github.com/Microsoft/visualfsharp int…

fdcf82a

…o proto

don't repeat bootstrap

e46dcd5

be systematic about verbosity

75e9cc3

Merge branch 'proto' of https://github.com/dsyme/visualfsharp into proto

d0f51d7

Merge branch 'master' of http://github.com/Microsoft/visualfsharp int…

63c64ef

…o proto

remove verbosity flags

8f09004

task builder insertion attempt

7b012b6

fix build

67d4815

cartermp added the Needs-RFC label Apr 24, 2019

Arnavion reviewed May 18, 2019

View reviewed changes

dsyme added 2 commits May 20, 2019 10:20

Merge branch 'master' of http://github.com/Microsoft/visualfsharp int…

8729822

…o tasks

remove boxing of result

3cf5a58

NinoFloris reviewed May 20, 2019

View reviewed changes

dsyme added 2 commits May 20, 2019 16:05

update for code review

171c40b

updates

bbe118d

update

12c3341

dsyme mentioned this pull request May 20, 2019

use proto build on mac and linux #6380

Merged

Merge branch 'proto' into tasks

636f8f5

dsyme added 3 commits May 21, 2019 13:29

fix incremental build

37e9d39

Merge branch 'inc4' into tasks

a0122d3

lift restriction on union cases in state machines

7625075

dsyme mentioned this pull request May 22, 2019

[RFC FS-1087, FS-1097, FS-1098] tasks, resumable state machines, inline on parameters #6811

Merged

27 tasks

dsyme closed this May 22, 2019

JustinWick mentioned this pull request Sep 12, 2021

Is Ply going to be obsolete? crowded/ply#24

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[WIP, RFC FS-1072] task and state machine support #6634

[WIP, RFC FS-1072] task and state machine support #6634

dsyme commented Apr 24, 2019 •

edited

Loading

dsyme commented Apr 24, 2019

dsyme commented Apr 24, 2019

cartermp commented Apr 24, 2019

Arnavion May 18, 2019

dsyme commented May 20, 2019

NinoFloris left a comment

NinoFloris May 20, 2019

dsyme May 20, 2019

NinoFloris May 20, 2019

dsyme May 20, 2019

NinoFloris May 20, 2019

dsyme commented May 20, 2019

NinoFloris commented May 20, 2019

dsyme commented May 20, 2019 •

edited

Loading

dsyme commented May 20, 2019

NinoFloris commented May 20, 2019

forki commented May 21, 2019

ashtonkj commented May 21, 2019

forki commented May 21, 2019

ashtonkj commented May 21, 2019

forki commented May 21, 2019

ashtonkj commented May 21, 2019

forki commented May 21, 2019

benaadams commented May 21, 2019 •

edited

Loading

dsyme commented May 22, 2019

[WIP, RFC FS-1072] task and state machine support #6634

[WIP, RFC FS-1072] task and state machine support #6634

Conversation

dsyme commented Apr 24, 2019 • edited Loading

Overview

Technical Note: Specifying generated state machines

Example: sync { ... }

Example: task { ... }

Example: taskSeq { ... }

Example seq2 { ... }

Examples list { ... }, array { ... }

Technical Note: Expected allocation profile for task { ... }

Performance Status

dsyme commented Apr 24, 2019

dsyme commented Apr 24, 2019

cartermp commented Apr 24, 2019

Arnavion May 18, 2019

Choose a reason for hiding this comment

dsyme commented May 20, 2019

NinoFloris left a comment

Choose a reason for hiding this comment

NinoFloris May 20, 2019

Choose a reason for hiding this comment

dsyme May 20, 2019

Choose a reason for hiding this comment

NinoFloris May 20, 2019

Choose a reason for hiding this comment

dsyme May 20, 2019

Choose a reason for hiding this comment

NinoFloris May 20, 2019

Choose a reason for hiding this comment

dsyme commented May 20, 2019

NinoFloris commented May 20, 2019

dsyme commented May 20, 2019 • edited Loading

dsyme commented May 20, 2019

NinoFloris commented May 20, 2019

forki commented May 21, 2019

ashtonkj commented May 21, 2019

forki commented May 21, 2019

ashtonkj commented May 21, 2019

forki commented May 21, 2019

ashtonkj commented May 21, 2019

forki commented May 21, 2019

benaadams commented May 21, 2019 • edited Loading

dsyme commented May 22, 2019

dsyme commented Apr 24, 2019 •

edited

Loading

Example: `sync { ... }`

Example: `task { ... }`

Example: `taskSeq { ... }`

Example `seq2 { ... }`

Examples `list { ... }`, `array { ... }`

Technical Note: Expected allocation profile for `task { ... }`

dsyme commented May 20, 2019 •

edited

Loading

benaadams commented May 21, 2019 •

edited

Loading