A Comparison of Python and Ruby Extension Interfaces (Re: Comparison between Python and "Ruby")

[Fernando Pereira]

In article <38215CE7.70C3D560 at compaq.com>, Greg Ewing
<greg.ewing at compaq.com> wrote:

> Fernando Pereira wrote:
> > 
> > What's the effect of this on portability? For instance, how are
> > pointers to live objects from the C stack handled? As is well-known,
> > this cannot be done portably.
> 
> It scans the whole C stack and marks anything that looks like
> it might be a pointer to a Ruby object. It assumes that setjmp()
> saves any registers that might contain such pointers. There are
> a few special cases coded in. Porting to a new system might
> require this piece of code to be adjusted, although it looks
> to me like it should work under most sensible architectures.

In my experience, there's a big difference between what you and I call
"sensible" and what compiler and OS developers try to get away with,
not to mention the vagaries of particular hardware. For example, what
is the state of the stack, registers, etc. when a Unix signal handler
is called? What if that handler (maybe by calling back into the
higher-level language) forces a GC?
> 
> Global variables in C extensions which contain Ruby pointers
> have to be explicitly made known during initialisation.
> 
> > > * Ruby seems to be able to raise exceptions without
> > > having to explicitly propagate them back out of routines,
> 
> > Same comment. There is no portable way of unwinding the C stack. What
> > does that mean for Ruby's portability?
> 
> It uses setjmp/longjmp. Presumably these work correctly on
> any system where they are implemented. Porting Ruby to a
> system where they're not implemented could be difficult.

Well, they are typically implemented, but they may not work as one
expects (eg. call longjmp from a signal handler). 

The reason I picked on both issues is that they have caused
never-ending problems for language implementations that want to coexist
flexibly with C and the OS. I've come to appreciate the choices made in
Python after spending many late, frustrating nights tracking down
obscure bugs in Prolog implementations, GNU Emacs ports (yes, GNU Emacs
*is* a language), Scheme scripting layers, and having talked often with
language implementers for other languages (eg. Lisp, ML) about how
tricky it is to get these things right in language implementations that
make too many assumptions about "sensible architecture", just to have
the next release of the C compiler or OS break things again.

-- F