[Pharo-dev] FFILibrary uniqueInstance

Ben Coman btc at openinworld.com
Mon Jan 14 06:29:02 EST 2019


On Mon, 14 Jan 2019 at 17:12, Esteban Lorenzano <estebanlm at gmail.com> wrote:

> Hi,
>
> On 14 Jan 2019, at 09:46, Guillermo Polito <guillermopolito at gmail.com>
> wrote:
>
> Hi Nicolas,
> On Fri, Jan 11, 2019 at 12:09 PM Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
>> Hi all,
>> I wanted to know if the moduleName was cached somewhere or recomputed at
>> each function call...
>> It seems to be recomputed.
>>
>
> Do you mean when using a symbol/string as module like...?
>
> ioFindSurface: id dispatch: dispPtr handle: handlePtr
> self ffiCall: #( bool ioFindSurface(int id, void * dispPtr, int
> *handlePtr) ) module: #SurfacePlugin
>
>
>>
>> We could have a different scheme:
>> moduleName is cached in a class inst var of FFILibrary.
>> FFILibrary is then added to startup list and moduleName is reset when
>> resuming on a different platform.
>> instance side moduleName calls class side moduleName.
>>
>> Or moduleName becomes an inst var, set during uniqueInstance
>> construction, and uniqueInstance is nilled out when resuming.
>>
>> What do you think?
>>
>
> As I see it, there are two (basic) schemas to do FFI calls using UFFI
>  - using a library object. Library objects are actual singletons stored in
> class instance variables
>
> FFILibrary class >> uniqueInstance
> self = FFILibrary
> ifTrue: [ self error: 'I''m an abstract class, use one of my children.' ].
> ^ uniqueInstance ifNil: [ uniqueInstance := super new ]
>
> - using a symbol/string, then a module is created dynamically
>
> String >> asFFILibrary
> ^ FFIUnknownLibrary name: self
>
> But, but :) the thing is that ffi calls in UFFI are lazily compiled using
> bytecode transformations and there (if I'm not mistaken) the library
> instances created are cached on the callout object stored as a literal in
> the method.
> So there is a cache, but per ffi call. And then, at shutdown, all the
> generated methods (bound to a specific external function) are wiped out.
>
> All this process is of course perfectible and probably a "coup de"
> profiling could be nice ^^.
>
>
> Well, when I designed the FFILibrary I first thought: let’s the user
> decide if they want to cache or not (because most of the time is not
> worthy, since as Guille says it is cached on each method and usually is
> straightforward)
> Then I thought that maybe I should add a generic cache mechanism, for
> those cases where you need to perform complicated locates. But I did not
> had the time to do it.
>
> So, I would say: yes, it would be good to have a cache mechanism, but most
> of the time is not needed (and caches are dangerous things so better to
> reduce their usage at max).
>

One thing that was get easily confusing is when when the moduleName is not
found it seems to cache that error,
so that even when the C-library is installed into the correct location it
continues to not find the function.
I should have added this to the bug tracker a while ago, but I haven't
checked for a while so I don't know if this is still the case.
I'll wait your response and if agreeable I'll add it to the P8 bug tracker.

cheers -ben




> If someone wants to implement that for their library, they can.
> If someone wants to implement a generic mechanism and contribute it, it
> would be also welcomed :)
>
> Esteban
>
>
>
> HTH,
> Guille
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20190114/9adcf1ae/attachment.html>


More information about the Pharo-dev mailing list