[Vm-dev] [ENH] Returning from context with sender == nil

[Igor Stasenko]

Just an idea..

currently, when returning from bottom context, which has no sender, VM
generates a message #cannotReturn:

You can checking by invoking:

(thisContext privSender: nil). ^ 5

which is fine, except that i think we can extend this behavior for use
in cases when we leaving the normal "smalltalk" execution
back to some C caller, namely:

- callbacks
- a "message send" from C

upon return from method (or block) , an interpreter always checks if
sender of a context (a caller context) is valid MethodContext
instance.
i am thinking about very small change, which will provide additional
functionality:
 - if context's sender in non-valid MethodContext, but instance of
SmallInteger, then
   we just assume that given smallinteger is an address of C function
which should be called (by stripping the tag bit of course).

The function is of kind:

   void (fn*) (sqInt returnValue).

i.e. upon discovering sender is smallint, an interpreter will call
this function with return value as argument.

As an option for additional safety, we can avoid using pure function
address in small integer instance, but instead
use a registry of valid addresses (so that smallint will be an index
in a table, where cool hackers can register own "No-return" handlers).
Then VM should check if sender is small integer, and if it is a valid
registered index in  "No-return" handlers table, and if its ok, then
call that function,
otherwise, do as usual and raise "cannot return exception".

You may argue, that same functionality can be achieved by using
special primitive(s). Which is true for callbacks, since we definitely
control the
callback entry, and on return we can invoke special primitive to
return back to C caller.
But thinking about future, imagine that we have an API in VM, similar
to Objective-C, which allows you to send a message to any object
and get a result:

/* C code */
resultOop = vmSend(receiver, selector, 3 /*num args */ , arg1, arg2, arg3);

here, we cannot control the execution , since potentially a C caller
may pick any receiver , any selector, so the entry point, unlike
from callbacks are not controllable at smalltalk side. However if we
use the proposed trick, upon return from the context,
we can clearly detect that it is time to return to C caller and handle
it accordingly.

What you think?

-- 
Best regards,
Igor Stasenko.