call primitive using PlatformFunction

[Michael Keppler]

Hi,

we have a repeated DLL call in our application, which takes around 2/3 of overall runtime. Currently that is done as user primitive, which takes a uint32 (pointer address) and a String and is coded as

Code: Select all

<primitive: 'lib': function>

I'd like to experiment with asynchronous resource calls to improve the performance of that DLL function. Therefore I want to call the same function as PlatformFunction (first synchronosly and as next step asynchronously). I tried several variants of creating that PlatformFunction (by looking at other PlatformFunction calls and the documentation), but all I got were primitiveFailed with "Unknown API type" (and I'm sure this primitiveFailed happens on the Smalltalk side, as I have a debugger attached to the DLL). My modified code looks like this:

Code: Select all

(PlatformFunction
                         callingConvention: 'userprim'
                         function: 'function'
                         library: 'lib'
                         parameterTypes: #(#uint32 #pointer)
                         returnType: #void)
callWith: address with: string.


Has anybody tried something like this before? Any other advice, what (probably stupid) mistakes I made?

Ciao and Thanks, Michael

[marten]

(PlatformFunction
callingConvention: 'userprim'
function: 'function'
library: 'lib'
parameterTypes: #(#uint32 #pointer)
returnType: #void)
callWith: address with: string.

Why not try "c" as calling convention ?

Marten

[wembley]

Michael -

Userprims are different from normal platform functions -- they are effectively extensions of the VM and cannot be called using async.

Marten has what is the best suggestion of you want to use async -- change the calling convention to 'C'. But you will also need to change the DLL code since it will now be passed a uint32 and a pointer instead of an Integer and a String object.

Whether or not changing to async will help depends on whether there are other things that your Smalltalk image can do while the DLL is running (and the Smalltalk process that called the DLL is waiting). If the Smalltalk logic depends on the result of the DLL before it can do anything else, async won't help.

[Michael Keppler]

When I asked this question, I did not have access to the DLL sources, that's why I went this way. Now I was able to modify the DLL and to additionally have the user primitive as a C function. The asynchronous resource future calls for that function work fine, and I measure a performance improvement on my hyperthreading only machine. My next step will be experimenting with multi core machines to see if I can even have parallel asynchronous calls to my DLL.

Thanks for your answers.