distributed runtime

[dol...@gmail.com]

Hi all and Happy New Year,

I was daydreaming the other day and I was wondering if it was possible to create some alternate runtime package.

The point would be to have the scheduler schedule goroutine not only on different CPU, but also on different CPU on different machines.

The system would be a binary that you could run as the scheduler or as a worker, and the scheduler would distribute among workers via some RPC. Of course, it would take cache optimisation to schedule it on the correct machine so they could share the same CPU when needed.

Is it a stupid idea? A very difficult one? A naive approach that would just have networking bandwidth and latency issues?

[Michael Jones]

Go is a shared memory system. Your challenge would be to understand a pointer that came to you from a different machine (i.e., remotely, the R in RPC).

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/5a05e457-4d9d-45b2-9822-d1accb48d7af%40googlegroups.com.

--

Michael T. Jones
michae...@gmail.com

[Justin Israel]

Seems like it would just be easier to explicitly schedule work over something like nats.io
At least you would have 100% control over what is distributed over the network.

[Jason E. Aten]

https://github.com/glycerine/goq

Network communication costs much more than in-proc, so its better to parallelize with whole independent processes.

[ffm...@web.de]

Have you heard of the Amoeba distributed OS? See https://en.wikipedia.org/wiki/Amoeba_(operating_system). Well, in Amoeba a thread can be suspended, thereafter be sent to some other machine where it is resumed. That you can't do with goroutines of course (and goroutines pursue a different approach anway). But I think you could take some ideas from Amoeba. There is also Plan9 to look at, see https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs or Sprite (https://en.wikipedia.org/wiki/Sprite_(operating_system).

All those things are bloody awful interesting things. Unhappily, to get anything accomplished that comes only near any of those things would be hell of a lot of work ...

[Brian Candler]

On Monday, 6 January 2020 08:36:56 UTC, ffm...@web.de wrote:

in Amoeba a thread can be suspended, thereafter be sent to some other machine where it is resumed.

Thread migration doesn't solve the OP's issue, because threads share memory with other threads: passing a copy of something is not the same as passing a pointer to something, unless you have a way for writes through a pointer to act on the original memory.

Ruby has(*) something like this in DRb.  If you pass an object over DRb, then at the far end a proxy object is constructed, so that method calls on that object are relayed back to the original host.

Systems with immutable values / pass-by-value only (e.g. Erlang) avoid this issue, since it doesn't matter whether you have a reference to a copy or the the original.

Regards,

Brian.

(*) or had: it's many years since I used Ruby in anger.

[Brian Candler]

On Monday, 6 January 2020 08:36:56 UTC, ffm...@web.de wrote:

in Amoeba a thread can be suspended, thereafter be sent to some other machine where it is resumed.

[ffm...@web.de]

Am Montag, 6. Januar 2020 09:54:49 UTC+1 schrieb Brian Candler:

On Monday, 6 January 2020 08:36:56 UTC, ffm...@web.de wrote:

in Amoeba a thread can be suspended, thereafter be sent to some other machine where it is resumed.

Thread migration doesn't solve the OP's issue, because threads share memory with other threads: passing a copy of something is not the same as passing a pointer to something, unless you have a way for writes through a pointer to act on the original memory.

Yes, you are right with that. I was dreaming a bit ... To extend the channel-based communication model in Go to a distributed setting you need "all or nothing" garanteed delivery of an item that is inserted into some distributed channel. Otherwise, in case of item to be placed in a distributed channel gets lost, the application may sit.

What is useful here is supervision as in the actor model (see 1, 2). If two parties comminucate through a network and get communication problems, a third party resets >both< communication parties that thereafter start anew. This is the approach that made applications written in Erlang fault-tolerant and highly stable.

However, if you want to apply supervision for distributed Go channels you have to change from channels to actors - at least behind the scenes of the distributed channels. AFAIK, no one has done something like that for anything writen in Go. Nats is very reliable, but does not provide guaranteed "all or nothing" delivery.

[1] https://erlang.org/doc/design_principles/sup_princ.html

[2] https://doc.akka.io/docs/akka/2.5/general/supervision.html

[ffm...@web.de]

However, if you want to apply supervision for distributed Go channels you have to change from channels to actors - at least behind the scenes of the distributed channels. AFAIK, no one has done something like that for anything writen in Go. Nats is very reliable, but does not provide guaranteed "all or nothing" delivery.

Coming to think of it you could make use of Rabbitmq as the distributed channel provider. It is written in Erlang and fulfills this "all or nothing" requirement. Bindings for Go already exist: https://godoc.org/github.com/streadway/amqp

[Robert Engels]

I’m pretty sure Nats.io has all of the same delivery guarantees as rabbitmq. What design is not accommodated by mats?

On Jan 6, 2020, at 4:56 AM, ffm...@web.de wrote:



However, if you want to apply supervision for distributed Go channels you have to change from channels to actors - at least behind the scenes of the distributed channels. AFAIK, no one has done something like that for anything writen in Go. Nats is very reliable, but does not provide guaranteed "all or nothing" delivery.

Coming to think of it you could make use of Rabbitmq as the distributed channel provider. It is written in Erlang and fulfills this "all or nothing" requirement. Bindings for Go already exist: https://godoc.org/github.com/streadway/amqp

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/52a565de-6c95-4a28-b8fd-1fc5bb6b1fb6%40googlegroups.com.

[Jason E. Aten]

On Mon, Jan 6, 2020 at 6:24 AM Robert Engels <ren...@ix.netcom.com> wrote:

I’m pretty sure Nats.io has all of the same delivery guarantees as rabbitmq. What design is not accommodated by mats?

 

Any design that needs flow control is not accommodated by Nats.io. I've used Nats extensively and consider it fundamentally flawed for data conveyance. It is only suitable for very light weight control messages that do not need to be delivered; where the application logic handles the retries instead of TCP.  Push any kind of data through Nats, and its lack of flow control means it will drop most all of your data on the floor.

[Robert Engels]

I think you want to use “nats streaming”. It does throttling via ACKs. 

On Jan 6, 2020, at 7:35 AM, Jason E. Aten <j.e....@gmail.com> wrote:



[dol...@gmail.com]

I completely forgot about this thread. I wanted to thank you all for your insights.

I've learned quite a few things, and can add many things to my "to dig" list!