

Go: Process isolation rediscovered as a programming pattern - petar
http://popalg.org/process-isolation

======
Jabbles
I think providing a language construct to help you do something badly and
covering up your mistakes by rebooting is a step in the wrong direction.

 _Surely, you can debug your programs, but catching slow leaks in complex
software is hard, even in Go._

I don't think this warrants restarting your goroutines. Go is still a young
language, who knows what tools for debugging will come along in the future.

~~~
masklinn
It depends what you're building. If what you're building is something which
should never fall over and die, and you can afford to (because the interesting
applicative state is stored elsewhere) kill-and-restart is a perfectly valid
strategy.

It is in fact one of the standard strategies in erlang supervision trees: a
subtree crashed, log the signal somehow and spawn a new subtree. No point in
interrupting the service if you don't absolutely have to.

If you have memory leaks in a subtree, you can just kill it and let things
recover in a standard manner, while you're investigating the cause of the leak
(or not, you may have more important stuff to do)

> Go is still a young language, who knows what tools for debugging will come
> along in the future.

While that's true, Go has not exactly been at the forefront of language
innovation so far and I've yet to see truly good tools for memleak
investigation and debugging in more innovative languages...

------
BarkMore
Are the concepts described in the article the same as Erlang or Erlang/OTP, or
is there more to it?

~~~
AndresNavarro
I'm not very knowledgeable about either Erlang or Go. But from what I read,
Erlang doesn't share objects between threads whereas Go does. This is a
serious difference, because as the article mention you have to decide what to
do if there are references from other threads. That's why the parallel with
processes breaks in the case of Go. Cleaning up the resources of a share
nothing (or little, and in a centralized place, see shared mem) process is
easy and fast. Cleaning up the resources of a share most/everything thread...
not so much.

~~~
masklinn
But that's the point is it not? TFA's building patterns to try to implement in
Go some of the most basic facilities of Erlang, and try to work around Go's
misfeatures (such as default shared memory).

So the concepts described in TFA do indeed already exist in Erlang.

~~~
AndresNavarro
Indeed. Erlang has this feature, I didn't intend to imply otherwise. What I
meant was that this mechanism would be more difficult to implement in Go.

~~~
masklinn
> What I meant was that this mechanism would be more difficult to implement in
> Go.

Well of course, since it needs to be implemented in the first place whereas
Erlang provides it as part of its core features.

------
inoop
The author seems to have rediscovered the advantages of managed operating
systems.

Here's a relevant article for those not familiar with the concept:

<http://research.microsoft.com/apps/pubs/?id=69431>

~~~
dchest
Why "managed"? Doesn't process isolation also works in normal operating
systems?

~~~
j_baker
I think the GP is getting at the author's discussions of the limitations of
GC. In some managed OSes that have come out, GCs are built in. Thus, file and
socket handles would be garbage collected.

~~~
dchest
But the author's proposal seem to be opposite to this: as he points out, it's
what current "normal" OSes do: having a command to terminate processes (and
thus, collect handles).

------
enum
Cool stuff. I think it's similar to custodians in Racket (the artist formerly
known as PLT Scheme):

[http://docs.racket-lang.org/reference/eval-
model.html#(part....](http://docs.racket-lang.org/reference/eval-
model.html#\(part._custodian-model\))

------
scott_s
If the problem looks like memory management, then perhaps something that looks
like garbage collection is the answer?

Of course, it doesn't map trivially, since there are no existing references to
goroutines. But, it may possible to determine if a goroutine cannot
communicate with anyone - it is garbage - if there is no one listening to any
of its channels. The one exception to this rule I can think of are daemon-
style goroutines that would interact with the system through external calls.
Such goroutines could be labeled as such at the creation site, indicating that
the goroutine manager should not manage them.

------
dchest
Discussion on go-nuts mailing list: [https://groups.google.com/d/msg/golang-
nuts/ar3QSMI4ooE/9LGK...](https://groups.google.com/d/msg/golang-
nuts/ar3QSMI4ooE/9LGKtLcyragJ)

------
j_baker
I see what the author is getting at, but I don't see the reason for a language
to provide this isolation. Why not just use an OS-level process? Why not
create a library or framework to do this?

~~~
masklinn
> Why not just use an OS-level process?

OS-level processes are very expensive (and the OS themselves may set quite
harsh limits on e.g. the number of processes you can have[0]) leading to lower
flexibility.

Furthermore, process-based IPC tends to be untyped (unless you're willing to
pay for the price of serialization and deserialization of higher-level
structures).

Finally, the ability to link processes together and react to events (mostly
death) of unrelated processes (no SIGCHLD and no SIGHUP) are limited.

[0] it defaults to 532 on a non-server Snow Leopard system, for instance...

~~~
andrewvc
nptl (read, any modern kernel) Linux processes are cheap, they share an
implementation with threads in fact. Note that this only means they can be
quite cheap, if you dirty a large amount of memory you lose CoW of course.

~~~
masklinn
> nptl (read, any modern kernel) Linux processes are cheap

They're not 300-bytes cheap. They're not you-can-have-a-million-of-them-on-a-
desktop-box cheap.

Erlang's processes are.

------
ww520
I think it's a good idea. Slow resource leaks are very hard to debug. Sometime
it's easier and cheaper to just restart the process. I seem to remember some
fighter jet subsystems can do fast reboot. When they crash, it can be
restarted in a faction of a second. If the rebooting approach works in a
realtime environment like that, it sure would work in the day-to-day
environment.

------
btilly
My first reaction is that this is a terrible idea.

Very often you create a goroutine to send messages down channels. Those
messages are objects. Those objects may go to multiple other goroutines.

Kill the originating goroutine and you've just messed up all of the other
goroutines that thought that they had objects.

~~~
masklinn
Erm... wouldn't the GC take care of that and keep the objects alive as long as
they're in the channels, or something?

~~~
btilly
He's talking about an extension that lets goroutines be preemptively killed,
and their memory freed. The mechanism he discussed would make an end run
around regular GC. My point is that it wouldn't play well with it.

------
upthedale
Seems loosely similar to how I'm using .Net4's Tasks from the Task Parallel
Library. I didn't particularly focus on the effects of the garbage collector
when I came up with my approach, but it does at least achieve point A in his
opening paragraph ( _(a) is simpler to use_ )

------
markbao
Getting this article in text/plain.

