4 ms·

A few years ago, I wouldn't have thought I would write this, but it looks like Microsoft is definitely changing, for the best! Two questions: - Does .NET Core

by ngrilly 10y ago

A few years ago, I wouldn't have thought I would write this, but it looks like Microsoft is definitely changing, for the best! Two questions: - Does .NET Core offers something similar to Go goroutines or Erlang "lightweight" processes? - And something similar to gofmt?

oblio 10y ago
1. I can't say for sure. Maybe this? http://getakka.net/ http://getakka.net/ 2. There's https://msdn.microsoft.com/en-us/library/ff926074.aspx https://msdn.microsoft.com/en-us/library/ff926074.aspx + your favorite IDE which can automatically reformat the code. Visual Studio can do this. If you want to enforce things, there's: https://stylecop.codeplex.com/ https://stylecop.codeplex.com/
jdmichal 10y ago
I don't know of any green threads in .NET -- at least, not built in. However, .NET does have a built-in thread pooling / task execution service. You generally interface via `System.Threading.Tasks.Task`[0], which has static `Run` functions, or use the `Factory` property to get the underlying `TaskFactory` for more fun. Since the executors are pooled, the creation costs will be amortized over your program's lifetime. Then there's `async`/`await`[1], which is built on top of tasks. [0] https://msdn.microsoft.com/en-us/library/system.threading.tasks.task%28v=vs.110%29.aspx https://msdn.microsoft.com/en-us/library/system.threading.ta... [1] https://msdn.microsoft.com/en-us/library/mt674882.aspx https://msdn.microsoft.com/en-us/library/mt674882.aspx
- int_19h 10y ago
  I remember that a long time ago, .NET threading was implemented in such a way that it should, in theory, support Win32 fibers. It's why all the low-level .NET APIs don't use the OS thread IDs, but instead have their own IDs, and require explicit mapping. I believe that it was abandoned as a supported scenario a while ago, though. But you can still see artifacts of that in the docs, e.g.: https://msdn.microsoft.com/en-us/library/system.threading.thread.managedthreadid(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/system.threading.th... "The value of the ManagedThreadId property does not vary over time, even if unmanaged code that hosts the common language runtime implements the thread as a fiber."
niba 10y ago
1. https://github.com/dotnet/orleans https://github.com/dotnet/orleans, here is an article about it http://thenewstack.io/project-orleans-different-than-erlang-designed-for-a-broad-group-of-developers/ http://thenewstack.io/project-orleans-different-than-erlang-... 2. https://github.com/dotnet/codeformatter https://github.com/dotnet/codeformatter
edgyswingset 10y ago
> Does .NET Core offers something similar to Go goroutines or Erlang "lightweight" processes? Not quite the same thing, but F# has the MailboxProcessor<'T> type which is conceptually similar to Erlang processes and can be used in the same way.
louthy 10y ago
Not out of the box, but this library does exactly that (with lots of functional niceness too). Disclaimer, I wrote it, so I'm obviously biased https://github.com/louthy/language-ext https://github.com/louthy/language-ext
- ngrilly 10y ago
  Just had a cursory look at the README. Is each lightweight process mapped to an OS thread? What is the minimal memory used by each lightweight process?
  - louthy 10y ago
    It wraps the F# MailboxProcessor mentioned in a comment above. A thread is only allocated when a message is processed, and then free'd up afterwards. So there's no permanent thread overhead and 100,000s can be created. The overhead in terms of memory is the internal state of each Process + the user's Process state. To see the internal overhead, check out the member variables for the Actor class [1]. It's pretty lightweight, although could probably shave a few bytes here and there. [1] https://github.com/louthy/language-ext/blob/master/LanguageExt.Process/ActorSys/Actor.cs https://github.com/louthy/language-ext/blob/master/LanguageE...

by ngrilly 10y ago

oblio 10y ago

1. I can't say for sure. Maybe this? http://getakka.net/ http://getakka.net/ 2. There's https://msdn.microsoft.com/en-us/library/ff926074.aspx https://msdn.microsoft.com/en-us/library/ff926074.aspx + your favorite IDE which can automatically reformat the code. Visual Studio can do this. If you want to enforce things, there's: https://stylecop.codeplex.com/ https://stylecop.codeplex.com/

jdmichal 10y ago

I don't know of any green threads in .NET -- at least, not built in. However, .NET does have a built-in thread pooling / task execution service. You generally interface via `System.Threading.Tasks.Task`[0], which has static `Run` functions, or use the `Factory` property to get the underlying `TaskFactory` for more fun. Since the executors are pooled, the creation costs will be amortized over your program's lifetime. Then there's `async`/`await`[1], which is built on top of tasks. [0] https://msdn.microsoft.com/en-us/library/system.threading.tasks.task%28v=vs.110%29.aspx https://msdn.microsoft.com/en-us/library/system.threading.ta... [1] https://msdn.microsoft.com/en-us/library/mt674882.aspx https://msdn.microsoft.com/en-us/library/mt674882.aspx

int_19h 10y ago
I remember that a long time ago, .NET threading was implemented in such a way that it should, in theory, support Win32 fibers. It's why all the low-level .NET APIs don't use the OS thread IDs, but instead have their own IDs, and require explicit mapping. I believe that it was abandoned as a supported scenario a while ago, though. But you can still see artifacts of that in the docs, e.g.: https://msdn.microsoft.com/en-us/library/system.threading.thread.managedthreadid(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/system.threading.th... "The value of the ManagedThreadId property does not vary over time, even if unmanaged code that hosts the common language runtime implements the thread as a fiber."

niba 10y ago

1. https://github.com/dotnet/orleans https://github.com/dotnet/orleans, here is an article about it http://thenewstack.io/project-orleans-different-than-erlang-designed-for-a-broad-group-of-developers/ http://thenewstack.io/project-orleans-different-than-erlang-... 2. https://github.com/dotnet/codeformatter https://github.com/dotnet/codeformatter

edgyswingset 10y ago

> Does .NET Core offers something similar to Go goroutines or Erlang "lightweight" processes? Not quite the same thing, but F# has the MailboxProcessor<'T> type which is conceptually similar to Erlang processes and can be used in the same way.

louthy 10y ago

Not out of the box, but this library does exactly that (with lots of functional niceness too). Disclaimer, I wrote it, so I'm obviously biased https://github.com/louthy/language-ext https://github.com/louthy/language-ext

ngrilly 10y ago
Just had a cursory look at the README. Is each lightweight process mapped to an OS thread? What is the minimal memory used by each lightweight process?
- louthy 10y ago
  It wraps the F# MailboxProcessor mentioned in a comment above. A thread is only allocated when a message is processed, and then free'd up afterwards. So there's no permanent thread overhead and 100,000s can be created. The overhead in terms of memory is the internal state of each Process + the user's Process state. To see the internal overhead, check out the member variables for the Actor class [1]. It's pretty lightweight, although could probably shave a few bytes here and there. [1] https://github.com/louthy/language-ext/blob/master/LanguageExt.Process/ActorSys/Actor.cs https://github.com/louthy/language-ext/blob/master/LanguageE...