Prev: tcl ssh extension library?
Next: Expect spawn expect
From: David N. Welton on 13 Nov 2009 09:05
On Nov 13, 1:28 am, "Donal K. Fellows"
<donal.k.fell...(a)manchester.ac.uk> wrote:

> They're not the same thing. Though there are some similarities,
> goroutines are parallel-schedulable and so are more like threads than
> coroutines (they are actually done as green threads over a native
> thread pool). There is a yield-like operation, but that's actually
> sending messages over a channel. They've still got a shared state
> model, though with some fairly grisly constraints on observability of
> state changes.

So... how similar are they to something like Erlang's "actor" model?
From: Donal K. Fellows on 14 Nov 2009 07:30
On 13 Nov, 14:05, "David N. Welton" <davidnwel...(a)gmail.com> wrote:
> So... how similar are they to something like Erlang's "actor" model?

They're fairly close to the actor model of Erlang and Scala though the
typed pi-calculus is even more representative (since you can send
channels over channels). It's not clear to me how Go handles
interactions with state outside a goroutine; there's some theoretical
impurity there, and the documentation provided so far doesn't make it
clear what the deep limitations are (and in fact deliberately
obfuscates things in order to encourage the use of channel
communications and probably to allow for flexibility of implementation
too).

Donal.
From: Will Duquette on 14 Nov 2009 09:20
On Nov 14, 4:30 am, "Donal K. Fellows"
<donal.k.fell...(a)manchester.ac.uk> wrote:
> On 13 Nov, 14:05, "David N. Welton" <davidnwel...(a)gmail.com> wrote:
>
> > So... how similar are they to something like Erlang's "actor" model?
>
> They're fairly close to the actor model of Erlang and Scala though the
> typed pi-calculus is even more representative (since you can send
> channels over channels). It's not clear to me how Go handles
> interactions with state outside a goroutine; there's some theoretical
> impurity there, and the documentation provided so far doesn't make it
> clear what the deep limitations are (and in fact deliberately
> obfuscates things in order to encourage the use of channel
> communications and probably to allow for flexibility of implementation
> too).
>
> Donal.

In the "golang-nuts" Google group there was a question about the
equivalent of thread-local storage for goroutines, and the answer was
that Go doesn't provide any such thing. So far as I can tell from
browsing around, global state is universally available in goroutines,
and you can get yourself tied in all of the usual concurrency knots if
you share data between goroutines in that way. In addition, the
runtime library has support for mutexes.

It sounds like the usual thing to do is to let goroutines allocate
their own state, and communicate through channels, rather than access
global state, in accordance with the "Doctor, it hurts when I do
this..." principle: "Well, Don't Do That, Then."
From: Donal K. Fellows on 14 Nov 2009 09:59
On 14 Nov, 14:20, Will Duquette <w...(a)wjduquette.com> wrote:
> In the "golang-nuts" Google group there was a question about the
> equivalent of thread-local storage for goroutines, and the answer was
> that Go doesn't provide any such thing.  So far as I can tell from
> browsing around, global state is universally available in goroutines,
> and you can get yourself tied in all of the usual concurrency knots if
> you share data between goroutines in that way.

They can fake goroutine-local state easily enough if they can get the
identity of the current goroutine. That's how Tcl does thread-locals
under the covers.

> In addition, the runtime library has support for mutexes.

If there are mutexes, they'll be sharing state. Nobody would use a
mutex if they weren't sharing state. (Mind you, you can also implement
a mutex using a goroutine...)

> It sounds like the usual thing to do is to let goroutines allocate
> their own state, and communicate through channels, rather than access
> global state, in accordance with the "Doctor, it hurts when I do
> this..." principle: "Well, Don't Do That, Then."

That was my impression too.

Donal.
From: tom.rmadilo on 14 Nov 2009 20:46
On Nov 12, 10:28 am, Will Duquette <w...(a)wjduquette.com> wrote:
> Has anyone who understands Tcl 8.6 coroutines looked at Google's new
> "Go" language and its "goroutines"?  (http://golang.org).
>
> From the little I know, it seems to me that Tcl 8.6 could support a
> very similar model of concurrency.

Looks like a cool language, from the hype, but one thing stuck out
which seems very promising:

* Go's type system has no hierarchy, so no time is spent defining the
relationships between types. Also, although Go has static types the
language attempts to make types feel lighter weight than in typical OO
languages.

Wow! Finally someone has dared to state the obvious: type hierarchy is
expensive and difficult to understand, even for a compiler.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9
Prev: tcl ssh extension library?
Next: Expect spawn expect