Am Donnerstag, 8. März 2018 10:17:02 UTC+1 schrieb Anto Aravinth: > > Thanks everyone and thanks Haddock for such a detailed response. Few > questions: > > On Thu, Mar 8, 2018 at 2:32 PM, Haddock <ffm...@web.de <javascript:>> > wrote: > >> The main difference is that goroutines do blocking takes from channels >> whereas actors receive asynchronous events. This means that actors have to >> deal with all the situations in asynchronous programming that are >> inherently difficult to deal with (inherently means there is no general way >> to solve this and never will be). >> > Why we are calling out its difficult to handle asynchronous programming? > I have done many node js project in real world, and for me if once you > understand how asynchronous programming works, its simple mental model. I > just feel interested, as you have said it would be difficult to handle > them. >
The fundamental problem with asynchronous programming is that asynchronous messages that depend on each other from the application logic "may not meet" and miss each other. Let's say, several threads start to search through a pile of data starting from different offsets. Somehen one thread has found the needle, now the other threads do not need to continue searching any more. How to tell them to cancel their search? This is not easy and therefore is a good simple example to show problems in asynchronous programming, but only a simple one. There are hell of problem situations of similar nature with asynchronous programming ... The problem with asynchronous programming is when doing concurrent things. When things run in parallel, there is no problem as there is no concurrency. Concurrency means that different threads need access to the data read and changed by other threads. A lot of business applications do things just in parallel. When someone changes his facebook page the change only concerns the account of that user, not of other users. Same for all other facebook users. So there is no concurrency and no difficulty in sychronizing shared state correctly between threads without race conditions, deadlocks, outlooks, live locks and all that. Because many business applications are parallel and not concurrent, actors or just plain threads work well. This is then misused by the marketing guys by saying that actors make multi-threading easy. It is only true when things are in parallel and there is no or little concurrency. With heavy concurrency CSP is just great (albeit not pre-emptive and not when distributed). > > >> >> The approach with blocking takes as in CSP and in Go runs into a problem >> when a thread blocked by an empty channel is lost for the application. >> Somehen then operationg system has no memory left to create new threads. >> This is being dealt with by having so called green threads (called >> goroutines in Go). Green threads have a reduced context and therefore >> consume less memory. On a machine with 4 GB RAM you can create about 2000 >> OS threads but about 80.000 goroutines (I once tried it out). So in Go you >> don't run into the problem that many empty channels with threads being >> blocked by them till they receive input can make the application go out of >> threads. >> > > I guess, its 80,000. Should be a typo. Also all goroutines are called as > green threads? I read somewhere they start with stack size of 4k, and > expand when needed. Correct me if I'm wrong here. > No typo, in my country the dot is the thousands separator ;-). But I will change to a comma when posting to an English speaking forum. Nice, not sure if coroutines in kotlin are same as Goroutine -- mainly they > also work as "green threads"? > You cannot have green threads on the JVM as the JVM does not have them. The workaround is to make use of fibers instead. See for example Quasar <http://docs.paralleluniverse.co/quasar/>, which is already doing that. Project Loom <http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html> inside Oracle is about making changes to the JVM to better support CSP-style additions. This video on youtube <https://www.youtube.com/watch?v=fpyub8fbrVE> is a good presentation about fibers by the creator of Quasar and the owner of project Loom at Oracle. > > >> >> Am Sonntag, 4. März 2018 18:00:54 UTC+1 schrieb Anto Aravinth: >>> >>> Hello All, >>> >>> I'm new to golang and trying to understand the difference between >>> channels and actors. From my knowledge: >>> >>> 1. Golang support channels, which is concurrently safe >>> 2. Channels can be shared across goroutines that are running. (very much >>> similar to messages) >>> >>> Actors: >>> 1. They are based on messages. >>> 2. Messages are immutable by nature. >>> 3. Actors work based on messages, concurrently. >>> >>> I find actors and channels much similar, may be I'm wrong here. Any help >>> would be really good. >>> >>> Thanks, >>> Anto; >>> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "golang-nuts" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/golang-nuts/uJxcfNsxh-0/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> golang-nuts...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
