On 5/18/2010 7:41 PM, Igor Stasenko wrote:
On 19 May 2010 04:38, Andreas Raabandreas.raab@gmx.de wrote:
And of course, when the very same people who have no clue about C and memory management corrupt their heap by the use of the FFI you get these complaints about how 'unstable' the system is. How very ironic.
That's not ironic. That's plain stupid. If people using FFI, and don't realizing what is 'direct memory access', and all consequences of it, then you will simply waste your time arguing with them about 'safety', whatever meaning they putting in it.
But i doubt you'll find such people. The point is, that there always should be a wrapping layer, written either in form of plugin or using FFI , which provides such safety.
See, this is where you're wrong. These problems are never *that* simple. If the stuff just crashes it'd be trivial to find. It's like concurrency bugs - when they're outright broken they're usually broken in 'easy' ways. However, the problems often show in forms where the system crashes unreproducibly two days before ship date. And the only way to work through this stuff is by proving yourself that the problem can't be here or there and to narrow it down to a place where you have a chance to find it.
To give an example, for a long time we had apparently random VM crashes due to using vertex arrays in OpenGL. The code was as simple as one could think; just pushing the gl[Vertex|Color|Normal]Pointers into the context and call glDrawArrays. We found that this would crash because (as the name implies) the state is 'client' state and the GL actually keeps a pointer to the data. So if the operations would be interrupted by a process switch, if that process would cause a (full) GC, and if that GC would collect enough data to free that memory region, then and only then it would crash. This is how these problems show; there's nothing outright 'stupid' about it. BTW, the solution: Moving the entire operation into a plugin so that all of it is atomic.
In any case, my definition of 'safety' is not the same you're implying above. It mostly relates to memory safety.
BTW, many of the sticky points you're mentioning could be fixed by having a 'panic' button for the VM that simply suspends all processes and fires up a single new process to listen on a port and take commands. SSH into the image and you can see what you can repair. And yet again, it's the VM that provides the way out here because your in-image handling of the panic button could already be compromised.
panic button won't help if you do Array setFormat: 88888. or Object become: nil.
Sure. I never said there'd be perfect safety. There's no such thing. But that doesn't mean you shouldn't try to improve things. And a panic button could make many situations much less problematic than they are today. But the point here really is that by having the VM, instead of the image, do that, you get a level of indirection that can help fixing the broken parts.
So, i'd rather focus on a such design, where direct manipulation with critical parts of environment is sufficiently guarded against fools, by using safety wrappers or multi-level capability-based mechanisms.
If you know how to use that to ensure that you're not dereferencing an invalid pointer I'm all ears. Seriously. If there's a safe way to use that stuff I'd love to use it.
I should also point out that there *are* ways to do that safely. It depends on whether the thing you're talking to is memory safe or not. In our products we ship a Python bridge where you talk from Squeak to Python and back. That bridge is safe and I have no problems exposing it because it's objects on either end. You never get your hands on a 'pointer' you only get our hands on a Python object in Squeak or a Squeak object in Python that you can send messages to. Since Python is GCed as well the bridge comes down to a bit of mapping between Squeak and Python objects and after that's it's a complete and open free-for-all (incl. callbacks, error propagation and more).
I'm completely game for a similar bridge to Java or .NET or any other memory safe object system. It's that memory unsafe stuff that I object to.
If you would ask me, how one could use smalltalk for scripting , then first thing, what we should do is to change VM to be a dynamically loadable library, with nice and consistent API.
Yes, indeed. When I wrote the bridge it was quite an eye opener. Both sides provide the same basic stuff, but what a difference in the interface! Clearly, the Python folks designed theirs to be used from C/C++ and clearly, we didn't ;-)
Cheers, - Andreas