[Vm-dev] FFI Plugin | Proposal: Add #doesNotCoerce:for: (like #doesNotUnderstand:)

[Marcel Taeumel]

Hi Fabio,

> I don't like the idea of adding a plugin-specific mechanism like this to the VM.

Why is that? The implementation strategy would be very clear: like #doesNotUnderstand:. It's just a new entry on the special objects array.

> There already is BAD_ARGUMENT, maybe there's a way to encode which argument is bad in the error code?

That wouldn't be any better. We could not support on-the-fly packaging of arguments for FFI calls by relying on just the error code. Without on-the-fly packaging, the FFI call could likely be unsafe (e.g. everybody using 'int' instead of the enum type as proposed in the library) or awkward to program (e.g., Alien callbacks require Smalltalk blocks to be warpped into Callback objects).

Best,
Marcel
Am 20.06.2020 22:05:29 schrieb Fabio Niephaus <lists at fniephaus.com>:
Hi Marcel:

On Fri, 19 Jun 2020 at 1:15 pm, Marcel Taeumel
wrote:

>
> Hi all!
>
> We have #doesNotUnderstand:, which is sent to the receiver when a message
> cannot be understood. Default reaction in Object is to raise
> MessageNotUnderstood exception.
>
> What if we could have a similar mechanism for FFI calls:
> #doesNotCoerce:for:. The receiver would be the one that made that call,
> should be an instance of ExternalLibrary, but could be any object. The
> arguments would be a pair of (argObject, argType) and the message (like the
> argument for doesNotUnderstand:) that represents the FFI call.
>

I don't like the idea of adding a plugin-specific mechanism like this to
the VM. I know it's not as convenient, but maybe something similar can be
achieved with error codes in fallback code? There already is BAD_ARGUMENT,
maybe there's a way to encode which argument is bad in the error code?

Fabio


> The pair of (argObject, argType) could be expressed as FFICallArgument:
>
> FFICallArgument
> argObject ...
> argType ...
>
> I suppose that such a new class would have to be reserved in the special
> objects array. An alternative would be to just use Array. Keep it simple.
> ;-)
>
> Default reaction could be to implement #doesNotCoerce:for: in Object (as
> *FFI-Kernel extension) to raise FFICallArgumentNotCoerced exception (to be
> implemented). Also, we could implement manual coercion in ExternaLibrary
> to, for example, wrap atomics into their aliasing structures.
>
> ExternalLibrary >> #doesNotCoerce: callArg for: message
> | argObject argType argIndex wrappedArg |
> argObject := callArg first. "or argObject accessor"
> argType := callArg second. "or argType accessor"
> argIndex := message arguments indexOf: argObject.
> wrappedArg := argType referentClass fromHandle: argObject.
> message arguments beWritableObject. "Just in case ;-)"
> message at: argIndex put: wrappedArg.
> ^ message sendTo: self
>
> Please share your thoughts. :-)
>
> Best,
> Marcel
>

Hi Marcel:

On Fri, 19 Jun 2020 at 1:15 pm, Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> wrote:

 
Hi all!

We have #doesNotUnderstand:, which is sent to the receiver when a message cannot be understood. Default reaction in Object is to raise MessageNotUnderstood exception.

What if we could have a similar mechanism for FFI calls: #doesNotCoerce:for:. The receiver would be the one that made that call, should be an instance of ExternalLibrary, but could be any object. The arguments would be a pair of (argObject, argType) and the message (like the argument for doesNotUnderstand:) that represents the FFI call.

I don't like the idea of adding a plugin-specific mechanism like this to the VM. I know it's not as convenient, but maybe something similar can be achieved with error codes in fallback code? There already is BAD_ARGUMENT, maybe there's a way to encode which argument is bad in the error code?

Fabio


The pair of (argObject, argType) could be expressed as FFICallArgument:

FFICallArgument
   argObject  ... <Object>
   argType ... <ExternalType>

I suppose that such a new class would have to be reserved in the special objects array. An alternative would be to just use Array. Keep it simple. ;-)

Default reaction could be to implement #doesNotCoerce:for: in Object (as *FFI-Kernel extension) to raise FFICallArgumentNotCoerced exception (to be implemented). Also, we could implement manual coercion in ExternaLibrary to, for example, wrap atomics into their aliasing structures.

ExternalLibrary >> #doesNotCoerce: callArg for: message
   | argObject argType argIndex wrappedArg |
   argObject := callArg first. "or argObject accessor"
   argType := callArg second. "or argType accessor"
   argIndex := message arguments indexOf: argObject.
   wrappedArg := argType referentClass fromHandle: argObject.
   message arguments beWritableObject. "Just in case ;-)"
   message at: argIndex put: wrappedArg.
   ^ message sendTo: self

Please share your thoughts. :-)

Best,
Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200622/b11e082c/attachment-0001.html>