Catching a hot potato

[Gor Gyolchanyan]

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.Leise at gmx.de> wrote:
> Am 15.10.2011, 14:18 Uhr, schrieb Gor Gyolchanyan
> <gor.f.gyolchanyan at 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.
>