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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Jun 19 13:05:39 UTC 2020


Hi Marcel,
Forget about FFIPlugin it's legacy

I'm currently changing ThreadedFFIPlugin to:
- enable passing ExternalData as atomicType by value
 The use case is the one of ExternalVariable
- enable ExternalData to have an ExternalStructure or ExternalTypeAlias as
type inst. var.
 and enable passing that to a corresponding
ExternalStructure/ExternalStructure pointer/ExternalTypeAlias/
ExternalTypeAlias pointer
- returning a new ExternalTypeAlias when returning such type by value

This way, we can make FFI a bit safer than using those void *


Le ven. 19 juin 2020 à 13:45, Marcel Taeumel <marcel.taeumel at hpi.de> a
écrit :

>
> Hi all, again. :-)
>
> I am aware that such a mechanism would have to be implemented in 2-times-7
> different places:
>
>
> Best,
> Marcel
>
> Am 19.06.2020 13:15:40 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
> 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.
>
> 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/20200619/0160db5a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32538 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200619/0160db5a/attachment-0001.png>


More information about the Vm-dev mailing list