New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Contribution idea: Proper support for F# #38

Open
sergeybykov opened this Issue Jan 28, 2015 · 49 comments

Comments

Projects
None yet
@sergeybykov
Member

sergeybykov commented Jan 28, 2015

No description provided.

@brodyberg

This comment has been minimized.

brodyberg commented Jan 29, 2015

I'd be interested in contributing here.

@sergeybykov

This comment has been minimized.

Member

sergeybykov commented Jan 29, 2015

Great! There are at least two problems here we are aware of.

  1. @johnazariah has an example of the "filthy hack" he had to do to work around what appears an incompatibility between F# async and TPL custom schedulers - https://gist.github.com/johnazariah/527287a190a14a73b35d#file-callergrain-fs. There is already a suggestion there from @vasily-kirichenko - https://github.com/fsprojects/fsharpx/blob/7246e314e3fdeae07f3465b9126f2bc22faa0cd5/src/FSharpx.Core/Async.fs#L43-L45.
  2. The bigger issue people have been pointing to is the fact that today you need to use interfaces, which is not natural for F#. The thought here is that a better 'binding' to F# is needed in the runtime. Being F# illiterate, I have very little idea what the right 'binding' should look like. We are open to all ideas.
@johnazariah

This comment has been minimized.

johnazariah commented Feb 1, 2015

@sergeybykov - thanks for raising the async issue
@vasily-kirichenko - thanks for the fix - i'll try it out

My thoughts on the second issue are as follows:

  1. The issue of idiomatic F# over Orleans is quite orthogonal to just the async support. My take on idiomatic F# is that the functional programming model prefers stateless functions operating on data which can be pipelined successively between functions, whilst the Orleans programming model has well encapsulated state and well defined semantics for updating internal state. I'm not sure how we are going to get a solution on this level that is both idiomatically F# and idiomatically Orleans.

  2. Digging a level deeper, I think the Orleans runtime has the makings of a streaming data provider, and with judicious use of stateless functions and stateful objects, we might be able to write distributed F# programs that take advantage of the scalability and reliability afforded by the Orleans runtime platform. (There is probably a lot to be gained on this front by looking at competing platforms like Apache Spark, which provide a Scala-based functional programming model over a highly-available redundant data storage layer)

@TonyAbell

This comment has been minimized.

TonyAbell commented Feb 1, 2015

We can also take guidance how existing distributed compute frameworks are surfaced

mbrace and Vagabond and FsPickler

akka.net F# example

Cricket example

One thing they all have in common is using Computation Expressions to hide all the boiler plate code. Taking place of the code Gen on the C# side.

Another issue is, there is already a concept of an Actors in F# as MailboxProcessors. Ideally we would map, Interface methods to a DU.

For example the Game Grain could be mapped to

type gamegrain =
 | AddPlayer of Guid
 | GetState of AsyncReplyChannel
 | GetMoves of AsyncReplyChannel
 | SetName of string
 | ....
@johnazariah

This comment has been minimized.

johnazariah commented Feb 1, 2015

@TonyAbell +1 :)

@yevhen

This comment has been minimized.

Contributor

yevhen commented Feb 1, 2015

@TonyAbell

One thing they all have in common is using Computation Expressions to hide all the boiler plate code. Taking place of the code Gen on the C# side.

Ye, but that requires having a non-static way to define an actors. Something which Orleans is currently lacking. You will need to define an interface first using C# and that immediately knocks-off F# fans :)

Another issue is, there is already a concept of an Actors in F# as MailboxProcessors. Ideally we would map, Interface methods to a DU.

'MailboxProcessor' and Akka's actor API - have a uniform interface. I'm not sure what will be the point of creating a mapper which will map from uniform interface to a non-uniform and vice versa. You either have one or another.

DU - is a Message. You do Message Handler selection yourself (via pattern matching). Which means that all of your functional grain interfaces will ever have 2 fully generic methods, at max. Something like this:

Task ReceiveTell(TRequest m);
Task<TResponse> ReceiveAsk(TRequest m);

Which raises a point: why you need to define any interfaces at all?!?

@yevhen

This comment has been minimized.

Contributor

yevhen commented Feb 1, 2015

@johnazariah We have tried Async.AwaitTask and it works perfectly. We've also introduced Async.AwaitVoidTask to await Tasks, that don't return results. And it covers the whole F# TPL-based async story. That is all.

@sergeybykov

This comment has been minimized.

Member

sergeybykov commented Feb 1, 2015

I believe @alan-geller also had some thoughts about F# integration.

@veikkoeeva

This comment has been minimized.

Contributor

veikkoeeva commented Feb 1, 2015

In the filthy hack code, on which scheduler does the last Async.StartAsTask run? If my memory serves me well (well, it can fail too), it doesn't run in the Orleans scheduler and according to documentation there isn't a way to specify a scheduler using Async like this.

@johnazariah

This comment has been minimized.

johnazariah commented Feb 1, 2015

@yevhen , @veikkoeeva that's precisely the issue - the Async.StartAsTask runs on a different scheduler as does the async {} monad, so making a grain call another grain (asynchronously) in F# does not work out of the box if you use the idiomatic async {} monad to sequence the calls...

@johnazariah

This comment has been minimized.

johnazariah commented Feb 1, 2015

@yevhen I think that having a way to create ad-hoc actor implementations (a-la mbrace, akka,net) and having a way to dynamically distribute them over the Orleans run-time so that you get the best of both worlds looks like the desired outcome! For this, there will have to be a way to dynamically create Orleans objects (with or without interfaces to define the capabilities) and ship them over the runtime...

@TonyAbell

This comment has been minimized.

TonyAbell commented Feb 1, 2015

maybe we could implement an orleansasync computational expression with the desired behavior.

workflow

@johnazariah

This comment has been minimized.

johnazariah commented Feb 1, 2015

@TonyAbell that's the simplest fix I could think of for the first issue, but perhaps vasily's solution is equally effective! :)

@yevhen

This comment has been minimized.

Contributor

yevhen commented Feb 2, 2015

@johnazariah

I think that having a way to create ad-hoc actor implementations (a-la mbrace, akka,net) and having a way to dynamically distribute them over the Orleans run-time so that you get the best of both worlds looks like the desired outcome! For this, there will have to be a way to dynamically create Orleans objects (with or without interfaces to define the capabilities) and ship them over the runtime...

We're working on this :) ...

@johnazariah

This comment has been minimized.

johnazariah commented Feb 2, 2015

@yevhen 👍

@ReubenBond

This comment has been minimized.

Contributor

ReubenBond commented Feb 2, 2015

@johnazariah have you looked into ActorFx? Maybe what you're looking for lies in the intersection between ActorFx and Orleans. The model can certainly be hosted within Orleans, with a little finagling. @sergeybykov, @gabikliot & I were talking about this a few days ago, actually.

We could have a generic, delegating implementation of an interface and provide a Become or SetImplementation method on it which takes a runtime implementation of its interface - certainly we would need to come up with a solid design, but it would be a heck of a lot of fun to work on :)

@johnazariah

This comment has been minimized.

johnazariah commented Feb 2, 2015

@ReubenBond I feel another learning session coming on :)

@TonyAbell

This comment has been minimized.

TonyAbell commented Feb 2, 2015

ActorFx seems dead or forgotten as the last check-in was Mar 19, 2014

How would you compare/contrast the ActorFx / m-brace frameworks.

@ReubenBond

This comment has been minimized.

Contributor

ReubenBond commented Feb 2, 2015

I'm not familiar enough with m-brace (@johnazariah knows more), but ActorFx provides a system for dynamically creating actors at runtime using a variety of languages (.NET, JavaScript, Python, afaik).

Actors can have their state automatically replicated (I believe they replicate the state of each actor after each method invocation, but I don't know). They are observable (actors can subscribe to other actors). And they are referenced by name.

It may not be active any more, but there are some concepts and possibly code which can be lifted & shifted into Orleans - perhaps as an optional dependency.

M-Brace looks like a distributed dataflow system, so maybe it's more similar to EventHubs than Orleans. Orleans could provide this model using steams as edges & grains as nodes.

Does M-Brace checkpoint flows, or are they restarted from scratch when there's a failure?

@veikkoeeva

This comment has been minimized.

Contributor

veikkoeeva commented Feb 2, 2015

Does M-Brace checkpoint flows, or are they restarted from scratch when there's a failure?

Taking a quick look at the docs it looks like the flows aren't explicitly checkpointed. From the Programming Model page

Clearly, one of the child computations will fail on account of an invalid url, creating an exception. In general, uncaught exceptions bubble up through Cloud.Parallel triggering cancellation of all outstanding child computations (just like Async.Parallel).

The interesting bit here is that the exception handling clause will almost certainly be executed in a different machine than the one in which it was originally thrown. This is due to the interpreted nature of the monadic skeleton of cloud workflows, which allows exceptions, environments, closures to be passed around worker machines in a seemingly transparent manner.

The MBrace manual goes deeper into details on what happens upon node failures or exceptions.

An important feature supported by cloud workflows is exception handling. Exceptions can be raised and caught in cloud workflows just as in any other piece of F# or .NET code.

cloud {
    try
        let! x = cloud { return 1 / 0 }
        return x + y
    with :? System.DivideByZeroException as e ->
        // log and reraise
        do! Cloud.Logf "error: %O" e
        return raise e
}

This snippet will execute in the anticipated fashion, recording a message to the log before completing the computation by re-raising the exception. It is, however, the distributed nature of MBrace that makes its exception handling mechanism particularly interesting. With cloud workflows, the symbolic execution stack winds across multiple machines. Thus as exceptions are raised, they are passed around multiple nodes before they are, if ever, returned to the user as a failed
computation result.

This is a good demonstration of what is one of the strengths of MBrace. Error handling in particular and computation state in general have a global and hierarchical scope rather than one that is fragmented and localized. This is achieved thanks to symbolic and distributed interpretation of what is known as monadic trampolines[10, 11], also known as the
“monadic skeleton” of a cloud workflow.

Having this mind, I was a few weeks ago thinking about MBrace and using Recalled to checkpoint calculations. There's a video of Recalled (1:15:55 onwards) and I was quite impressed in Helsinki F# meetup of the performance that saturated the memory bus when doing (arbitrary) checkpointed calculations. Recalled is imporessive, as is Hopac (of which @vasily-kirichenko knows more) on which it's built on.

As an aside, it would be interesting to combine MBrace, Recalled and something like FSCL (OpenCL accelerated computing, say, with FPGAs) and with a quick look it's like Spark on steroids, only in F# and .NET. Naturally with Orleans (somehow).

@vasily-kirichenko

This comment has been minimized.

vasily-kirichenko commented Feb 2, 2015

/cc @VesaKarvonen

@vasily-kirichenko

This comment has been minimized.

vasily-kirichenko commented Feb 2, 2015

As an aside, it would be interesting to combine MBrace, Recalled and something like FSCL (OpenCL accelerated computing, say, with FPGAs) and with a quick look it's like Spark on steroids, only in F# and .NET. Naturally with Orleans (somehow).

I don't see why we need Orleans in this mix at all :) MBrace has its own integration with Azure.

@yevhen

This comment has been minimized.

Contributor

yevhen commented Feb 2, 2015

+1

понедельник, 2 февраля 2015 г. пользователь Vasily Kirichenko написал:

As an aside, it would be interesting to combine MBrace, Recalled and
something like FSCL (OpenCL accelerated computing, say, with FPGAs) and
with a quick look it's like Spark on steroids, only in F# and .NET.
Naturally with Orleans (somehow).

I don't see why we need Orleans in this mix at all :) MBrace has its own
integration with Azure.


Reply to this email directly or view it on GitHub
#38 (comment).

@veikkoeeva

This comment has been minimized.

Contributor

veikkoeeva commented Feb 2, 2015

I don't see why we need Orleans in this mix at all :) MBrace has its own integration with Azure.

Orleans doesn't look like being a good fit for computationally heavy, or algorithmic work, but fits well for more "infrastructure kind" of work, I feel. Plus I'm still a lot more skilled cranking C# code, like many others. :)

For what its worth, I contemplated on creating an on-premises cluster of GPU boxes (or FPGAs if the prices of OpenCL accompanied ones come down) as there isn't GPGPU in Azure and use this from MBrace. Then I'd farm out computational work from an Orleans cluster. Naturally it's a long way to action here, but one can always envision...

@johnazariah

This comment has been minimized.

johnazariah commented Feb 2, 2015

@vasily-kirichenko Orleans has more than the function shipping element. For example, mbrace's data sharing mechanism is though external means (like Azure storage) which isn't great for data locality! Orleans also has built-in mechanisms for dealing with dynamic scale in terms of compute...

@jthelin jthelin added the enhancement label Feb 2, 2015

@dsyme

This comment has been minimized.

dsyme commented Feb 7, 2015

I've glanced over this thread and have one particular request

There are a number of references to the interaction between F# Async and custom task schedulers, e.g. manifest here: https://gist.github.com/johnazariah/527287a190a14a73b35d#file-callergrain-fs with a link to a possible adjustment to FSharp.Core here: https://github.com/fsprojects/fsharpx/blob/7246e314e3fdeae07f3465b9126f2bc22faa0cd5/src/FSharpx.Core/Async.fs#L43

What I'd like to ask is - should we be making a fix and/or extension to FSharp.Core here for 4.4.0.0 to address this problem? Would adding a new overload to AwaitTask be appropriate?

In the meantime, is the linked FSHarpx method (copied below) a sufficient workaround?

type Async = 
      static member AwaitTask(task:Tasks.Task, ?cancellationToken) = 
           let cancel = defaultArg cancellationToken Async.DefaultCancellationToken 
           Async.AwaitTask (task.ContinueWith<unit>((fun t -> ()), cancel))

Please give your feedback ASAP by proposing a course of action at http://github.com/Microsoft/visualfsharp

@veikkoeeva

This comment has been minimized.

Contributor

veikkoeeva commented Feb 7, 2015

I remember Vladimir Matveev, or desco provided an alternative implementation at SO thread Async.Await not catching Task exception. I'll just replicate it here (but see the comment made by eulerfx on the original thread):

open System.Threading.Tasks

module Async =
    let AwaitTask (t: Task) = 
        Async.FromContinuations(fun (s, e, c) ->
            t.ContinueWith(fun t -> 
                if t.IsCompleted then s()
                elif t.IsFaulted then e(t.Exception)
                else c(System.OperationCanceledException())
                )
            |> ignore
        )

I had a related question Translating async-await C# code to F# with respect to the scheduler and I got quite afar with Orleans and F# by using FSharpx. Ultimately, though, when I got into more complex code, I got the same code running more smoothly just with plain C# (I'm a rather n00b with F#).

I think one of the problems I came across with FSharpx was that it called task.Result in the TaskBuilder, which caused a deadlock in the grains code. Then a myriad of other things, one of which was this awaiting tasks. Unfortunately I haven't had time to go deeper into this.

<edit: Some context for awaiting tasks:
https://stackoverflow.com/questions/24623120/await-on-a-completed-task-same-as-task-result

@sergeybykov

This comment has been minimized.

Member

sergeybykov commented Feb 7, 2015

Calling Task.Result or Task.Wait() on an uncompleted task would definitely be a problem as it would block the thread and violate the very thing we are trying to do in the scheduler - run lots of non-blocking async operations on a small one-thread-per-core thread pool.

@veikkoeeva

This comment has been minimized.

Contributor

veikkoeeva commented Feb 17, 2015

I don't see why we need Orleans in this mix at all :) MBrace has its own integration with Azure.

Orleans doesn't look like being a good fit for computationally heavy, or algorithmic work, but fits well for more "infrastructure kind" of work, I feel. Plus I'm still a lot more skilled cranking C# code, like many others. :) For what its worth, I contemplated on creating an on-premises cluster of GPU boxes (or FPGAs if the prices of OpenCL accompanied ones come down) as there isn't GPGPU in Azure and use this from MBrace. Then I'd farm out computational work from an Orleans cluster. Naturally it's a long way to action here, but one can always envision...

Albeit off-topic, but as mentioned already, I'll add a quote here OneNet looks like being just this. Would this be a reason to start learning F# in anger and perhaps Recalled and Hopac too? :) Interesting video from 1:16 onwards. Perhaps Microsoft should hire Vesa to do some OneNet work -- especially as he understands both hardware and software, library writing, theoreticals and who knows what (yes, I praise too much, it's just that those libraries feel awesome still). /cc @VesaKarvonen

@smoothdeveloper

This comment has been minimized.

Contributor

smoothdeveloper commented Mar 1, 2015

Hello all, sorry I haven't yet read this thread entirely, I'm willing to push some efforts on this task to help have F# as a standard supported language for all aspects of Orleans.

UPDATE: It seems there are a lot of discussion going on about the serialization and generating dynamic assemblies to replace static code generation, so I'm unsure if supporting other languages the way it is done for the 3 supported is going to see major investments until this decision gets sorted out...

Right now I've worked on adding project template for F# Grain interfaces and looking at the unimplemented methods in FSharpCodeGenrator.

Regarding all the discussions about diverging from what C#/VB.NET are doing, I think it would be better in a first release of full F# support to just do what is done in the two other languages:

  • use interfaces (F# support them fine, using union type as shown by @TonyAbell doesn't allow method overloads that are supported in other languages)
  • use TPL tasks (I know it doesn't look like most idiomatic F# but it will work the same as other languages, and there are ways to handle TPL tasks in F# code)
  • have the CodeGenerator on par with C#/VB.NET ones

Once we have that, and the complete set of project templates, F# will be a first class citizen and we can consider extending the code generator to make it expose other ways to interact with the grain in a F# idiomatic way.

My two cents.

For now I'm experimenting with adding crude implementation of missing methods in code generator, to make the Grain Interface project template.

Please let me know if those efforts are useless or if we agree that first milestone is having F# exposing same features as the two other languages, even if it's not the most polished.

Thanks for your feedback.

@gabikliot

This comment has been minimized.

Contributor

gabikliot commented Mar 1, 2015

That's a great plan @smoothdeveloper! We are all for it. And thank you for your help!

@sergeybykov

This comment has been minimized.

Member

sergeybykov commented Mar 2, 2015

@smoothdeveloper I agree. Thank you!

It looks like the incompatibility with async/await and TPL custom schedulers is the immediate blocker here. It causes a deadlock in a grain that tries to make an async call, which appears like an F# issue that @dsyme, @vasily-kirichenko, and @veikkoeeva were discussing above.

@yevhen

This comment has been minimized.

Contributor

yevhen commented Mar 2, 2015

Just don't use async {}. Instead use task {}, That is all. It works 100% and code looks much better. It's absolutely the same and don't require useless conversion from TPL to Async, back and forth.

@vasily-kirichenko

This comment has been minimized.

vasily-kirichenko commented Mar 2, 2015

@yevhen I think this entire conversation is about proper or idiomatic F# support. It's clear that we can use Tasks directly (or create a syntactic sugar in form of a task {} CE), but nobody does this in F#. TPL is rarely used (directly).

@sergeybykov

This comment has been minimized.

Member

sergeybykov commented Mar 2, 2015

@vasily-kirichenko Are you saying it's not worth it to fix the TPL integration issue before/in parallel with the idiomatically proper integration with F#?

@dsyme

This comment has been minimized.

dsyme commented Mar 2, 2015

@sergeybykov @vasily-kirichenko @yevhen I very much support the plan outlined above - to first get "working" F# support in Orleans, and then progress to consider "idiomatic" F# support.

@dsyme

This comment has been minimized.

dsyme commented Mar 2, 2015

The F# computation expression support was definitely designed with permitting task { ... } in mind. We never defined a task-builder because it isn't often needed in F#. However it seems it is needed when interacting with frameworks that make heavy use of customized TPL task schedulers - of which Orleans is the most significant at the moment.

So in this context it's fine to define and use a task { .. } builder.

@smoothdeveloper

This comment has been minimized.

Contributor

smoothdeveloper commented Mar 3, 2015

@gabikliot short notice on what I'm up to so far:

  • draft of Grain Interface F# project template, I think this side is close to be working out of the box
  • few hacks in FSharpCodeGenerator class to replace the NotImplementedException with stubs to allow me to step through the code
  • emitting some CodeSnippetTypeMember in GetBasicReferenceMethod, this apparently get called through the logic in base class
  • added some logic in Output method to itterate through the ReferencedNamespace.Types and their members to append to the stream.

So it seems I'm able to get started with trying to hack that side of the code generation, and will see if I can get it to a point where I have code that compiles for the FSharpHelloWorld project.

I'll push a branch in my fork to get help / review from you guys and keep track of small progresses I can make.

Basic question, if my changes break something in the FSharp grain implementation side, is there any tests that would light up? Are there any tests for the ClientGenerator project? I don't see anything in the main solution in "Show Project Dependency Diagram".

@veikkoeeva

This comment has been minimized.

Contributor

veikkoeeva commented Mar 3, 2015

@smoothdeveloper Take a note of some issues mentioned earlies with regard to plain Tasks and FSharpx task builder. I may have used task builder wrong as I got code using it deadlock easier than just with 'await' (running Orleans with, say, XS PaaS instances).

Otherwise I'm all for F# if I can feel sure that when I code the execution doesn't leak off from the Orleans scheduler. Maybe this is even easier with F# when the groundwork has been laid down.

@sergeybykov A tangential question, what's the feeling if one were to introduce something like F# for testing or Fake for building, that is more on the development process and perhaps some helper libraries? I'm not suggesting, but just probing the general feeling if in the future someone would have something that useful in Orleans.

@sergeybykov

This comment has been minimized.

Member

sergeybykov commented Mar 3, 2015

@veikkoeeva Personally, I'd like to learn more about both. F#-based tests seem like all goodness. I assume we'll need to fix the Task issue first because most meaningful tests (whether we call them unit or integration tests :-)) will involve making calls to grains and awaiting results.

Is Fake in any way compatible with MSBuild/VS? With all idiosyncrasies of MSBuild, it is relatively easy to have a nice F5 experience. How does it work with Fake?

If there is enough interest, we should probably create a separate issue for this.

@smoothdeveloper

This comment has been minimized.

Contributor

smoothdeveloper commented Mar 3, 2015

@sergeybykov regarding FAKE, it's very easy to call a solution build from it, it also figures out the evironment paths, it means you can run it from a console.

At my work, it took me very short time to get started with FAKE scripts to do tasks like building, running tests, creating database, generating code.

The main advantage is that it's basically F# code using a nice helper library, so when you edit the script in VS you get feedback if you type something which doesn't make sense.

@gabikliot

This comment has been minimized.

Contributor

gabikliot commented Mar 3, 2015

@smoothdeveloper The plan sounds good.
Regarding the tests, we do have some, but we need to clean them up first. They are mixing code gen testing and programing model testing. We'll do it, but it will take some time. For now, you can use the FSharpHelloWorld sample and the existing unit tests and samples.

@gabikliot gabikliot changed the title from Proper support for F# to Contribution idea: Proper support for F# May 1, 2015

@veikkoeeva

This comment has been minimized.

Contributor

veikkoeeva commented Oct 1, 2015

T4-like templating tool with support for F#. Might be useful if not going for [F# Compilers Services ("Roslyn")](F# Compiler Services) route.

@jthelin jthelin added help wanted and removed help wanted labels Jan 7, 2016

@sergeybykov sergeybykov added this to the Backlog milestone Jan 7, 2017

sebastianburckhardt pushed a commit to sebastianburckhardt/orleans that referenced this issue Apr 24, 2017

TestRunner as a base class that all implementations need to fulfill (d…
…otnet#38)

* TestRunner as a base class that all implementations need to fulfill

This is to reduce boilerplate test code that might become stale, when adding/changing expectations, or when asserting more things.

* Included missing test as SkippableFact

@lambdakris lambdakris referenced this issue Jun 15, 2017

Open

Native support for task { ... } #581

5 of 6 tasks complete
@ShalokShalom

This comment has been minimized.

ShalokShalom commented Mar 9, 2018

How is the current state?

@veikkoeeva

This comment has been minimized.

Contributor

veikkoeeva commented Mar 9, 2018

@ShalokShalom Support for F# types has improved (though F# specific types aren't generated) and https://github.com/OrleansContrib/Orleankka has progressed significantly and is used in production. The Orleankka people likely have the most accurate picture with the current usage. @ReubenBond can probably tell something about the ideas with Roslyn. As you know already (from F# GH issues), there is this Roslyn, project spaces etc. thingamajig that would make the overall picture more seamless.

@ReubenBond

This comment has been minimized.

Contributor

ReubenBond commented Mar 11, 2018

In addition to Orleankka, we have an F# sample in the Samples directory which makes use of a task Computation Expression from Giraffe for async. As far as code generation is concerned, there are two options:

@ShalokShalom

This comment has been minimized.

ShalokShalom commented Mar 11, 2018

Apache Storm uses OS isolation and Akka pure cooperative objects on OS threads.

How does Orlean do this?

@ReubenBond

This comment has been minimized.

Contributor

ReubenBond commented Mar 11, 2018

@ShalokShalom do you mean to ask, "How does Orleans isolate user grains from each other?"
That's not related to F# support, but we don't use any strict enforcement. Instead, we make doing so unnatural. There is no natural way for grains to pass CLR references to each other. Of course, any model can be circumvented - but that has never been an issue as far as I'm aware. That is, we've never seen a user somehow unintentionally have grains directly reference each other, breaking isolation. If you'd like, we can discuss this in Gitter: https://gitter.im/dotnet/orleans

EDIT: in addition to the above, there are also checks to guard against undesired thread-hopping. For example, if you attempt to access something while not executing under the correct context, then an exception is thrown.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment