[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The Golang UK Conference

Go Oyvind! Â(pun intended!)
Marc

On Wed, Apr 8, 2015 at 7:16 AM, Teig, Oyvind BIS <Oyvind.Teig@xxxxxxxxxxxxxxxx> wrote:

Have just registered for http://www.golanguk.com/ - the Friday before CPA 2015!-)

Â

Ãyvind

Â

PS. I donât think Silence is golden with respect to the below..

Â

From: occam-com-request@xxxxxxxxxx [mailto:occam-com-request@xxxxxxxxxx] On Behalf Of Ãyvind Teig
Sent: 31. mars 2015 22:50
To: Jon Kerridge
Cc: Ãyvind Teig; Roger Shepherd; Jim Whitehead II; Rick Beton; Occam Family
Subject: [External] Re: Go - deadlocked processes causing memory leaks

Â

Hi all

1.ÂÂÂÂÂ Is this (the whole thread, starting with Rickâs question 29March2015) so important that it should be updated in the original stackoverflow thread?

2.ÂÂÂÂÂ Or in some way added to golang-nuts, or better golang-dev?

3.ÂÂÂÂÂ If not, is there a place where it could be posted?Â

4.ÂÂÂÂÂ If so, should it be anonymized or edited?

5.ÂÂÂÂÂ Or is it already on some Occam Family open thread (or else) out there?

6.ÂÂÂÂÂ Or is this news to us only, and the Go people are content with their present solution?

7.ÂÂÂÂÂ An easy solution could be to make a pdf of it and place it somewhere, and then refer this somewehere?

8.ÂÂÂÂÂ Any other question in need of an answer?

Ãyvind

Â

Â

31. mar. 2015 kl. 14.05 skrev Kerridge, Jon <J.Kerridge@xxxxxxxxxxxx>:

Â

Hi,

version 1.4.2 does not help; in fact the effect is even worse.

Â

I am developing the code using Eclipse with the plugin goclipse in a Windows 7 system (my normal system)

Â

When I ran my code it started and produced some output, albeit slowly. It then stopped and caused my PC to hang such that Cntrl-Alt-Del did not work and I had to resort to switching off the PC using the power switch!!

Â

If anyone wants the code they can find it atÂhttps://bitbucket.org/jkerridge/gowsÂ

Â

Jon

Â

Â

Â

Professor Jon Kerridge
School of Computing
Edinburgh Napier University
Merchiston Campus
Edinburgh EH10 5DT

Â

0131 455 2777

Â

From:Âoccam-com-request@xxxxxxxxxxÂ[occam-com-request@xxxxxxxxxx] on behalf of Kerridge, Jon [J.Kerridge@xxxxxxxxxxxx]
Sent:Â30 March 2015 10:46
To:ÂRoger Shepherd; Jim Whitehead II
Cc:ÂRick Beton; Occam Family
Subject:ÂRE: Go - deadlocked processes causing memory leaks

That is my experience!!

Â

I shall now try the latest 1.4 release of the language to see if there have been any changes to the run time to get rid of the problem I found.

Â

I will let you know

Â

Jon

Â

Â

Â

Professor Jon Kerridge
School of Computing
Edinburgh Napier University
Merchiston Campus
Edinburgh EH10 5DT

Â

0131 455 2777

Â

From:Âoccam-com-request@xxxxxxxxxxÂ[occam-com-request@xxxxxxxxxx] on behalf of Roger Shepherd [rog@xxxxxxxx]
Sent:Â30 March 2015 09:35
To:ÂJim Whitehead II
Cc:ÂRick Beton; Occam Family
Subject:ÂRe: Go - deadlocked processes causing memory leaks

So the memory leak is, arguably, correct behaviour then?

Â

Roger

--

Roger Shepherd

Â

Â

Â

On 29 Mar 2015, at 22:01, Jim Whitehead II <jnwhiteh@xxxxxxxxx> wrote:

Â

There is no such thing as a goroutine going out of scope, there's no process hierarchy. It's spawned in a flat tree and will continue to block indefinitely. Yes it would be possible for the garbage collector to determine that a channel send could never succeed on that channel but the semantics of what to do after that are very difficult to specify.

Â

- Jim

Â

On Sun, 29 Mar 2015 at 22:19 Roger Shepherd <rog@xxxxxxxx> wrote:

Â

On 29 Mar 2015, at 17:35, Rick Beton <rick.beton@xxxxxxxxx> wrote:

Â

Hi Roger,

Â

see notes inserted below...

Â

On 29 March 2015 at 17:01, Roger ShepherdÂ<rog@xxxxxxxx>Âwrote:

Â

I think I understand the explanation in Stack Overflow. Essentially this says that if a one-buffered channel is used, the sending process wonât block even if the receiver is dead, and the process and channel will be garbage collected. Presumably in the implementation, a processâs memory is reclaimedÂonlyÂwhen it terminates, whereas dangling channels are garbage collected.

Â

Â

That is a reasonable interpretation. Go has quite straightforward memory model, using the stack as much as possible and the garbage-collected heap otherwise. Anything that goes out of scope is reclaimed either by being on the stack (and the stack pointer is moved), or by having no more references to it. This applies to both the channel and the goroutine in the specific example.

Â

Â

Â

Â

In the example, isn't it the case that with the zero-buffered channel the channel and the grouting go out of scope and should be garbage collected? So there is a bug, as the Stack Overflow post suggests.

Â

Roger

--
Roger Shepherd
rog@xxxxxxxx

Â

Ãyvind TEIGÂ
+47 959 615 06
oyvind.teig@xxxxxxxxxxx
http://www.teigfam.net/oyvind/home
(Mac)

Â