Catching a hot potato

[Sean Kelly]

Is this a scenario where you've determined that the performance difference prevents the app from running as intended?

Sent from my iPhone

On Oct 15, 2011, at 6:19 AM, Gor Gyolchanyan <gor.f.gyolchanyan at gmail.com> wrote:

> 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.
>>