22

Go のスローガンの 1 つは、メモリを共有して通信しないでください。代わりに、通信によってメモリを共有します

私は、Go が同じマシン上で実行されている 2 つの異なる Go コンパイル済みバイナリを相互に通信できるようにするかどうか (つまり、クライアント サーバー) と、C++ の boost::interprocess と比較してどれくらい高速になるかを考えています。これまで見てきたすべての例は、同じプログラム ルーチン間の通信を示しているだけです。

シンプルな Go の例 (個別のクライアント コードとサーバー コードを使用) をいただければ幸いです。

4

3 に答える 3

7

これを読んで最初に思ったことの 1 つは Stackless Python でした。Go のチャネルは Stackless Python の多くを思い起こさせますが、それは (a) 私がそれを使用したことがあり、(b) それらが実際に由来する言語/考えに触れたことがないためである可能性があります。

チャネルを IPC として使用しようとしたことは一度もありませんが、それはおそらく、代替手段の方がはるかに安全である可能性が高いためです。ここにいくつかの疑似コードがあります:

プログラム1

chan = channel()
ipc = IPCManager(chan, None)
send_to_other_app(ipc.underlying_method)

chan.send("Ahoy!")

プログラム2

chan = channel()
recv_from_other_app(underlying_method)
ipc = IPCManager(chan, underlying_method)

ahoy = chan.recv()

従来の IPC 方式を使用する場合は、通信をその上にラップするチャネルを両側に配置できます。これにより、実装でいくつかの問題が発生し、対処方法についても考えられず、いくつかの予期しない競合状態が発生する可能性があります。

ただし、同意します。Go チャネルと同じ柔軟性を使用してプロセスを介して通信する機能は、驚異的です (しかし、私は不安定になることを恐れています)。

ただし、単純なソケットを両側にチャネルでラップすると、ほぼすべての利点が得られます.

于 2009-11-13T17:27:07.737 に答える
2

MPIライブラリをラップするために同様のことを行うことを検討しました。私の現在の考えは、次のようなものを使用することです

func SendHandler(comm Comm){
    // Look for sends to a process
    for {
        i := <-comm.To;
        comm.Send(i,dest);  
    }
}
func ReceiveHandler(comm Comm){
    // Look for recieves from a process
    // Ping the handler to read out
    for {
        _ = <-comm.From;
        i := comm.Recv(source);
        comm.From <- i;
     }
}

ここで、comm.Sendとcomm.Recvはac通信ライブラリをラップします。2つの異なるプログラムのチャンネルをどのように設定するかはわかりませんが、そのようなことは経験がありません。

于 2009-11-13T21:24:57.343 に答える