I'm assuming that Léa is using Hashicorp's gRPC plugin approach for Go (https://github.com/hashicorp/go-plugin) or similar, and that executable really does mean a separate program in a separate process.
As Robert points out, it is possible to share memory if you really want to between processes. As Sharon points out, you probably should not. :) Rather you should change the signature of your remote procedure call to exec2 to return the update you want made as a returned value, and let exec1 apply the change itself. If you are using Hashicorp's approach, the whole idea there is that your main program can be fault-tolerant against badly behaved "plugins". Thus while a traditional (C world) plugin would be in the form of a shared library (an .so or DLL) loaded into the same process, in the Hashicorp gRPC approach, your "plugin" is really a separate process. This trades off stability for a little less performance. The plugin process can crash, or restart, or even be upgraded, without taking down the main exec1 program. That's a pretty big benefit, and the main reason folks use that approach (plus you cannot unload DLLs from Go without crashing the runtime, so its almost but not quite mandatory). The only tradeoff is that going over the network with gRPC is slightly slower performance wise. Unless you are doing stuff where perf is critical, and given the question that is unlikely, then the separate process approach of Hashicorp/gRPC to "plugins" is much nicer. In fact the next step if you need perf is to move from TCP to unix domain sockets (before looking at shared memory). Unix domain sockets are fast enough for Chrome, for instance, and still give you nice isolation/fault tolerance. On Saturday, July 26, 2025 at 8:12:39 PM UTC+1 Robert Engels wrote: > The OP doesn’t understand how gRPC works. It doesn’t have an in process > mode that could share pointers. Everything is serialized and copied. The OP > is confused because the generated gRPC code uses pointers in the stubs. > > On Jul 26, 2025, at 2:00 PM, Jon Perryman <jon.pe...@gmail.com> wrote: > > > > > The standard and correct way to handle this is to embrace the > client-server nature of gRPC. > > I could easily be wrong but my interpretation is that exec1 does not > involve gRPC. It's implied that exec1 and exec2 are in the same process > because the op expects the pointer will reference the same storage without > using shared memory. This is not unusual for C but GO requires the use of > the UNSAFE class which should be avoided. > > Without details, we are guessing at what the OP is attempting to achieve. > We're assuming that gRPC is the right solution for the problem being solved. > > On Sat, Jul 26, 2025 at 4:07 AM Sharon Mafgaoker <sha...@cloud5.co.il> > wrote: > >> The Correct Approach: Return the Updated Value >> >> The plugin (exec2) should perform its logic and then *return the >> modified data* back to the main application (exec1). >> >> The workflow should be: >> >> 1. >> >> *exec1 (Client):* Calls a gRPC function on exec2, passing the current >> state of the item in the request. >> 2. >> >> *exec2 (Server):* Receives the item (as a copy), performs its updates >> on that copy. >> 3. >> >> *exec2 (Server):* Returns the fully updated item in the gRPC response. >> 4. >> >> *exec1 (Client):* Receives the response and updates its original item >> with the returned data. >> >> >> >> Sharon Mafgaoker – Senior Solutions Architect >> >> M. 050 995 99 16 | sha...@cloud5.co.il >> >> >> >> >> On Sat, 26 Jul 2025 at 4:06 Robert Engels <ren...@ix.netcom.com> wrote: >> >>> You can’t typically do this from user code. You should used shared >>> memory or a memory mapped file, or socket communication. >>> >>> On Jul 25, 2025, at 7:20 PM, Léa Galet <leaesper...@gmail.com> wrote: >>> >>> >>> Hi, >>> I have 2 executables in go (called exec1 and exec 2) >>> exec1 is the main application, loading exec2 as a grpc plugin >>> Exec 1 is the one making the calls to exec 2, so there's a possibility >>> of downward communication >>> i wanted my exec2 to be able to update some values of an item passed >>> from exec1 so i gave the item as a pointer (wanted to use the inline update >>> property of pointers) >>> unfortunatly, in exec2 it's a copy of the pointer and not the pointer >>> directly (i printed the pointer adresses to be sure) >>> i don't seem to find a definitive answer anywhere so >>> Is there a method to have exec2 use the same pointer as exec1? >>> >>> -- 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+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/0b696709-7ed8-46c9-93a6-6e9200409edcn%40googlegroups.com.
