Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Problem with that is that it is less efficient than a shared library but also susceptible to the same issue, namely that if you change the interface then things break.

Edit: It does of course get you extra functionality, like being usable over a network connection. Trade offs.



How is it less efficient?


Directly dispatching a function via a call per the ABI of your computer vs producing a serialized message stream, sending it to another process, deserializing a stream and then calling the function.

Yes, it's less efficient.

The better question might be "did it matter in practice?".


I once replaced an export operation that depended on COM calls to Excel with some text manipulation code and brought the run time down from 30 minutes to an hour to just a few seconds. So in at least that case it did matter in practice.


It involves syscalls and data copying. How could it not be less efficient?


There are examples of very efficient IPC, just not in UNIX-land. If your IPC system is integrated with the scheduler, the difference between a dynamic library call and IPC can be minimized into irrelevance.


I was not certain that data serialization and copying is required. Is that always true? You can’t do IPC with some shared memory setup?


Inside one application OK but for other use it'd be a security and stability nightmare: less memory protection..




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: