是否可以跨进程使用函数指针？
我知道每个进程都会创建自己的内存地址空间，但是我想知道，
如果进程 A 有一个像 : 这样的函数
int DoStuff() { return 1; }
和一个像 : 这样的指针 typedef
typedef int(DoStuff_f*)();
和一个像 : 这样的 getter 函数
DoStuff_f * getDoStuff() { return DoStuff; }
以及一种与进程 B 通信的神奇方式通过...说 boost::interprocess
是否可以将函数指针传递给进程 B 并
直接从进程 B 调用进程 A 的 DoStuff ？
I'm aware that each process creates it's own memory address space, however I was wondering,
If Process A was to have a function like :
int DoStuff() { return 1; }
and a pointer typedef like :
typedef int(DoStuff_f*)();
and a getter function like :
DoStuff_f * getDoStuff() { return DoStuff; }
and a magical way to communicate with Process B via... say boost::interprocess
would it be possible to pass the function pointer to process B and call
Process A's DoStuff from Process B directly?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
不。函数指针只是进程地址空间中的一个地址。它没有不同过程所特有的内在标记。因此，即使您的函数指针恰好在您将其移至 B 后仍然有效，它也会代表进程 B 调用该函数。
例如，如果
进程 A 和 B 正在运行相同的代码，您最终可能会在相同的地址处得到相同的函数 - 但您仍然会使用 B 的数据结构和全局内存！所以简短的回答是，不，这不是您想要的方式！
此外，诸如地址空间布局随机化之类的安全措施可以防止此类“技巧”发挥作用。
你混淆了 IPC 和 RPC。 IPC 用于通信数据，例如对象或文本块。 RPC 用于使代码在远程进程中执行。
No. All a function pointer is is an address in your process's address space. It has no intrinsic marker that is unique to different processes. So, even if your function pointer just happened to still be valid once you've moved it over to B, it would call that function on behalf of process B.
For example, if you had
If process A and B are running the same code, you might end up with identical functions at identical addresses - but you'll still be working with B's data structures and global memory! So the short answer is, no, this is not how you want to do this!
Also, security measures such as address space layout randomization could prevent these sort of "tricks" from ever working.
You're confusing IPC and RPC. IPC is for communicating data, such as your objects or a blob of text. RPC is for causing code to be executed in a remote process.
简而言之，您不能使用传递给另一个进程的函数指针。
函数代码位于内存的受保护页中，您无法对其进行写入。并且每个进程都有独立的虚拟地址空间，因此函数地址在另一个进程中无效。在 Windows 中，您可以使用这篇文章中描述的技术将代码注入到另一个中进程，但最新版本的 Windows 拒绝它。
您应该考虑创建一个将在两个进程中使用的库，而不是传递函数指针。在这种情况下，当您需要调用该函数时，您可以向另一个进程发送消息。
In short, you cannot use function pointer that passed to another process.
Codes of function are located in protected pages of memory, you cannot write to them. And each process has isolated virtual address space, so address of function is not valid in another process. In Windows you could use technique described in this article to inject your code in another process, but latest version of Windows rejects it.
Instead of passing function pointer, you should consider creating a library which will be used in both processes. In this case you could send message to another process when you need to call that function.
这就是为什么人们发明了 COM、RPC 和 CORBA 等东西。它们中的每一个都提供了这种通用的能力。正如您所猜测的，每个人的工作方式都与其他人略有不同。
Boost IPC 并不真正支持远程过程调用。它将允许将变量放入共享内存中，以便两个进程可以访问该变量，但如果您想使用 getter/setter 来访问该变量，则必须自己执行此操作。
这些基本上都是包装器，用于生成“美味”版本的东西，但你可以在没有它们的情况下完成。例如，在 Windows 中，您可以自行将变量放入共享内存中。您可以在 Linux 中执行相同的操作。 Boost 库是一个围绕这些库的相当“薄”的库，它允许您为 Windows 或 Linux 编写相同的代码，但不会尝试在此基础上构建很多代码。 CORBA（例如）是一个更厚的层，提供了一个相对完整的分布式环境。
This is why people have invented things like COM, RPC and CORBA. Each of them gives this general kind of capability. As you'd guess, each does so the job a bit differently from the others.
Boost IPC doesn't really support remote procedure calls. It will enable putting a variable in shared memory so its accessible to two processes, but if you want to use a getter/setter to access that variable, you'll have to do that yourself.
Those are all basically wrappers to produce a "palatable" version of something you can do without them though. In Windows, for example, you can put a variable in shared memory on your own. You can do the same in Linux. The Boost library is a fairly "thin" library around those, that lets you write the same code for Windows or Linux, but doesn't try to build a lot on top of that. CORBA (for one example) is a much thicker layer, providing a relatively complete distributed environment.
如果您尝试使用进程 B 中的进程 A 的函数指针，您将不会调用进程 A - 您将调用进程 B 中相同地址的任何内容。如果它们是同一个程序，您可能会很幸运，并且会是相同的代码，但它无法访问进程 A 中包含的任何数据。
If you tried to use process A's function pointer from process B, you wouldn't be calling process A - you'd call whatever is at the same address in process B. If they are the same program you might get lucky and it will be the same code, but it won't have access to any of the data contained in process A.
函数指针对此不起作用，因为它只包含代码的起始地址；如果相关代码不存在于其他进程中，或者（由于地址空间随机化之类的原因）位于不同位置，则函数指针将毫无用处；在第二个过程中，它会指向某个东西，或者什么也不指向，但几乎肯定不是你想要的地方。
如果你疯了^Wdaring，你可以将实际的指令序列复制到共享内存上，然后让第二个进程直接跳转到它 - 但即使你可以让它工作，该函数仍然会在进程 B 中运行，而不是在进程 B 中运行。进程A。
听起来你想要的实际上是某种消息传递或RPC系统。
A function pointer won't work for this, because it only contains the starting address for the code; if the code in question doesn't exist in the other process, or (due to something like address space randomization) is at a different location, the function pointer will be useless; in the second process, it will point to something, or nothing, but almost certainly not where you want it to.
You could, if you were insane^Wdaring, copy the actual instruction sequence onto the shared memory and then have the second process jump directly to it - but even if you could get this to work, the function would still run in Process B, not Process A.
It sounds like what you want is actually some sort of message-passing or RPC system.
如果两个进程都在同一个应用程序中，那么这应该可以工作。如果您尝试在应用程序之间发送函数指针，那么您就不走运了。如果您假设进程和线程是同一事物，但事实并非如此，我最初的答案是正确的。其他答案是正确的 - 不同的进程不能共享函数指针（或任何其他类型的指针）。
If both processes are in the same application, then this should work. If you are trying to send function pointers between applications then you are out of luck.My original answer was correct if you assume a process and a thread are the same thing, which they're not. The other answers are correct - different processes cannot share function pointers (or any other kind of pointers, for that matter).