FFI Callbacks

Alejandro F. Reimondo aleReimondo at smalltalking.net
Fri Sep 1 19:08:27 UTC 2006


Hi Diego,

> I know that <> is used in primitives, but in calls to external
> libraries there is a performance reason for this kind of notation?

The method will be activated ONLY on primitive failure.
Activation of method contexts requires processing.
In this situation, the api call will run faster than normal methods.
You must have in mind that the #invoque:... -#call:-
 methods are also primitive methods.
IMHO the reason to use short notation is that it preserve
 the value of senders/implementors ... (user performance reason)

> Have this kind of methods different bycodes (like in primitives) or
> it's only a shorthand for the longer expression?

The api methods are identical to primitive methods, their
 bytecode will be used only on call/primitive failure.
It is success, no bytecode is executed (no method activation).

The no-activation of contexts is an important point to
 consider with FFI mechanisms because it relates with
 the general perfomance.

> > Dynamic function calls (instantiate functions on demand)
> >  can be used, but are more long expressions.
> > With dynamic functions you can call more than
> >  one function in a method, but invalidate
> >  senders/implementors as a powerful tool for browsing
> >  (#call:with:... will return all API calls in the universe).
> > Using <...> syntax let you choose better (smalltalk) selectors
> >  for calls and let you bind the calls without reducing
> >  browsing effectiveness.
>
> What are the differences in browsing?

If you call the senders of #call: a huge amount of calls
 will be reported (all API calls use the same message).
When you use <...> notation, the senders & implementors
 works as usual, retrieving the senders of the API you
 are searching.

> I don't see much appart from less typing, since you can find
> references to ExternalLibraryFunction, and follow some "best practice"
> to declare the function in one place.

The function will be "declared" once if you implement it in one method. :-)
Implementing a function and using it as an object requires
 a global reference.
The reference will be hidden in a method if <...> notation is used.

[si no se entiende, decime y te escribo en castellano a tu casilla]
cheers,
Ale.


----- Original Message ----- 
From: "Diego Fernandez" <diegof79 at gmail.com>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Friday, September 01, 2006 3:40 PM
Subject: Re: FFI Callbacks


> On 9/1/06, Alejandro F. Reimondo <aleReimondo at smalltalking.net> wrote:
> > The <...> syntax is a short syntax notation to make a method
> >  as a primitive method, calling a function (object) like
> >  you instantiate for platformFunction (the object will be
> >  instantiated by the compiler and bounded to the method
> >  as a primitive) and returning the result (following normal
> >  primitive failure policy).
>
> I know that <> is used in primitives, but in calls to external
> libraries there is a performance reason for this kind of notation?
> Have this kind of methods different bycodes (like in primitives) or
> it's only a shorthand for the longer expression?
>
> > Dynamic function calls (instantiate functions on demand)
> >  can be used, but are more long expressions.
> > With dynamic functions you can call more than
> >  one function in a method, but invalidate
> >  senders/implementors as a powerful tool for browsing
> >  (#call:with:... will return all API calls in the universe).
> > Using <...> syntax let you choose better (smalltalk) selectors
> >  for calls and let you bind the calls without reducing
> >  browsing effectiveness.
>
> What are the differences in browsing?
> I don't see much appart from less typing, since you can find
> references to ExternalLibraryFunction, and follow some "best practice"
> to declare the function in one place.
>
> Regards,
> Diego.-
>




More information about the Squeak-dev mailing list