The only reason why i don't want to resort to IPC is the run-time overhead. calling a function takes a few assembly instructions, sending messages between threads take a few thousand (if not more) assembly instructions.
On Sat, Oct 15, 2011 at 5:03 PM, Marco Leise <marco.le...@gmx.de> wrote: > Am 15.10.2011, 14:18 Uhr, schrieb Gor Gyolchanyan > <gor.f.gyolchan...@gmail.com>: > >> Thanks for the detailed answer. >> Example of when i would like to recover from a segfault: >> I have different independent parts of an app, which MAY cooperate. If, >> however, one of them crashes (e.g. they come from different sources) >> the other one will continue to work but without the cooperation >> functionality. > > You could see if you can ensure safe operation of the extensions with @safe. > Other than that, the only way to protect your core application is to run the > extensions in separate processes, thus giving them their own address space. > Modern browsers run plugins in a separate process for example. > You can communicate with the child process in the usual ways: stdout/stdin > pipe, shared memory or more elaborate systems. A serialization library like > Orange might come handy at that point. > And before you say that this is a bad solution, because you cannot call > functions directly, remember that in the days of 16-bit DOS an application > extension could not only crash the host application, but the whole operating > system. > Now that I think about it, it should be possible to generate some function > stubs for inter process communication in D from an interface declaration. > But that's probably to much work for a single project. >
