"Raab, Andreas" <Andreas.Raab at disney.com> wrote:
> > Gruess Gott!  This sounds very cool.  I had a thought though. 
> > Why don't we split the job between 2 VMs, with some shared 
> > memory, and let theother VM be the one that crashes.  
> > Be able to detect and log it, and restart another VM.  
> > Flag that call as disabled and keep going?  
> 
> Interesting idea. There are a couple of problems with it though. The biggest
> problem is that Squeaks object memory can be corrupted by calls to external
> functions. There is no way to check this and the effect is not immediate
> (e.g., usually the system will crash at the next garbage collection and this
> may be *way* after you've actually done the bad stuff). Thus, you would
> basically need to clone the entire image for each call (ouch) until you know
> it's in a stable state again. And not only the image - it can be similarily
> bad if you corrupt any VM state so you'd basically have to clone the entire
> process (e.g., VM+image). A little too much work just for calling some
> function ;-)
> 

Hmm.

If you provide the proper hook, many OS's would allow marking the image
as read-only during the execution of a foreign function.  In Unix you
would use mprotect.  If you only want to protect the image itself, then
it would just be a single call to protect the entire image, and another
call to undo it.  It wouldn't exactly be zippy, but it might be
tolerable.

On even better OS's, you could probably have separate threads which each
have different memory protection setups.  Call the foreign function in
the thread which has the image protected, and then resume normal
operation in a thread with the image being writable.  This approach
would probably be easier on the memory management hardware.

I suspect that Linux, with it's very flexible clone() call, could be
convinced to work this latter way.

Still, it doesn't seem critical to me.  Hopefully you are only going to
use FFI for existing libraries that are pretty stable.

Lex