Smalltalk › Pharo › Pharo Smalltalk Users

UFFI asynchronous callbacks

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

ASAM

UFFI asynchronous callbacks

I use Pharo 8(64bit) UFFI to call a dll(64bit).
Over the dll I have access to 1 or more hardware devices.
The dll has a function where I can register a call-back function.
The callback is invoked whenever a hardware is connected or disconnected
from PC.

At the moment, Pharo always crashes when the callback is executed by the
dll.

Before I waste my time trying to find the bug.
I wanted to ask first… Is Pharo supporting asynchronous callbacks?

I also found this old thread but the last entry is from 2017.
http://forum.world.st/UFFI-with-asynchronous-callbacks-td4993968.html#a5014328
Now I wanted to check the current status.

Thanks for your help.

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Ben Coman

Re: UFFI asynchronous callbacks

Callbacks are supported... http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-4-ast-walking-with-visitors-callbacks/

but I'm not sure about the "asynchronous" part of your query.

cheers -ben

On Sat, 18 Jul 2020 at 19:56, ASAM <[hidden email]> wrote:

I use Pharo 8(64bit) UFFI to call a dll(64bit).
Over the dll I have access to 1 or more hardware devices.
The dll has a function where I can register a call-back function.
The callback is invoked whenever a hardware is connected or disconnected
from PC.

At the moment, Pharo always crashes when the callback is executed by the
dll.

Before I waste my time trying to find the bug.
I wanted to ask first… Is Pharo supporting asynchronous callbacks?

I also found this old thread but the last entry is from 2017.
http://forum.world.st/UFFI-with-asynchronous-callbacks-td4993968.html#a5014328
Now I wanted to check the current status.

Thanks for your help.

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

ASAM

Re: UFFI asynchronous callbacks

Hello Ben,

I quickly made a dummy DLL to limit the problem to the essentials.

I think my problem comes more from how I use the semaphore.

I wanted to do that:

only "semaphore signal",
But that somehow doesn't work.
Now i'm doing that "[ Processor yield. semaphore signal ] fork" (it work's)
but i don't know if that's a good idea.

ffiCallback
^ FFICallback signature: #( void #( uint32 foo ) ) block: [ :foo |
Transcript
show: 'API Funktion value: ' , foo asString, ' activePriority:',
Processor activePriority asString; cr.

"that's working"
[ Processor yield. semaphore signal ] fork.

"that usually works 80%."
"[ semaphore signal ] fork"

"that crashes pharo almost always."
"semaphore signal"
]

I also have a little problem, too. Why can I use my own C-Type UNUM32 at
...self ffiCall: #( T_ERROR StartMyThreadFunction(UNUM32 millisecondsToFire)
).
But with FFICallback signature: # (void # (uint32 foo)) I get an error
"Unable to resolve external type: UNUM32. Why is that?

Thanks for your help.

testDllForAsyncCallback.dll
<http://forum.world.st/file/t372350/testDllForAsyncCallback.dll>
testDllForAsyncCallback.cpp
<http://forum.world.st/file/t372350/testDllForAsyncCallback.cpp>
testDllForAsyncCallback.h
<http://forum.world.st/file/t372350/testDllForAsyncCallback.h>
testDllForAsyncCallback.h
<http://forum.world.st/file/t372350/testDllForAsyncCallback.h>
UFFICallback.st <http://forum.world.st/file/t372350/UFFICallback.st>
CTypes.st <http://forum.world.st/file/t372350/CTypes.st>
<http://forum.world.st/file/t372350/Transcript.png>

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Ben Coman

Re: UFFI asynchronous callbacks

Hi Asam,

On Sun, 19 Jul 2020 at 21:38, ASAM <[hidden email]> wrote:
>
> Hello Ben,
>
> I quickly made a dummy DLL to limit the problem to the essentials.

Great idea. A more generic example is attractive for people to
examine and help out.
I browsed the code but I'm sorry it needs a deeper expertise than I have.
Hopefully someone working on the threaded FFI will tune in.

In the meantime, it won't solve your query but you may find this
interesting to watch...
Strategies for Non-Blocking FFI
https://www.youtube.com/watch?v=L_QFwsNOMAc

cheers -ben

>
> I think my problem comes more from how I use the semaphore.
>
> I wanted to do that:
>
> only "semaphore signal",
> But that somehow doesn't work.
> Now i'm doing that "[ Processor yield. semaphore signal ] fork" (it work's)
> but i don't know if that's a good idea.
>
>
> ffiCallback
> ^ FFICallback signature: #( void #( uint32 foo ) ) block: [ :foo |
> Transcript
> show: 'API Funktion value: ' , foo asString, ' activePriority:',
> Processor activePriority asString; cr.
>
> "that's working"
> [ Processor yield. semaphore signal ] fork.
>
> "that usually works 80%."
> "[ semaphore signal ] fork"
>
> "that crashes pharo almost always."
> "semaphore signal"
> ]
>
> I also have a little problem, too. Why can I use my own C-Type UNUM32 at
> ...self ffiCall: #( T_ERROR StartMyThreadFunction(UNUM32 millisecondsToFire)
> ).
> But with FFICallback signature: # (void # (uint32 foo)) I get an error
> "Unable to resolve external type: UNUM32. Why is that?
>
> Thanks for your help.
>
> testDllForAsyncCallback.dll
> <http://forum.world.st/file/t372350/testDllForAsyncCallback.dll>
> testDllForAsyncCallback.cpp
> <http://forum.world.st/file/t372350/testDllForAsyncCallback.cpp>
> testDllForAsyncCallback.h
> <http://forum.world.st/file/t372350/testDllForAsyncCallback.h>
> testDllForAsyncCallback.h
> <http://forum.world.st/file/t372350/testDllForAsyncCallback.h>
> UFFICallback.st <http://forum.world.st/file/t372350/UFFICallback.st>
> CTypes.st <http://forum.world.st/file/t372350/CTypes.st>
> <http://forum.world.st/file/t372350/Transcript.png>
>
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>

tesonep@gmail.com

Re: UFFI asynchronous callbacks

Hi, as Ben correctly pointed out there is the alternative of using a
Queue based approach for FFI.
It is available as a plugin for the headless VM and it can be used with Pharo 8.
It is here: https://github.com/pharo-project/threadedFFI-Plugin
The plugin is already compiled and shipped with the VM.
It is only required to load the Smalltalk side code with:

Metacello new
baseline: 'ThreadedFFI';
repository: 'github://pharo-project/threadedFFI-Plugin';
onConflictUseLoaded;
load.

This is fully integrated as a backend of UFFI, so all the code you
already have it will be working fine.
You need to give more information to select the callout strategy to
use (https://github.com/pharo-project/threadedFFI-Plugin/wiki/Using-with-UFFI)

Using TFFI it is possible to receive callbacks from other threads and
process them in the VM thread.

If you need any help, please feel free to ask in the list, so it can
be useful for everybody.
Cheers,

Pablo

On Sun, Jul 19, 2020 at 6:32 PM Ben Coman <[hidden email]> wrote:

>
> Hi Asam,
>
> On Sun, 19 Jul 2020 at 21:38, ASAM <[hidden email]> wrote:
> >
> > Hello Ben,
> >
> > I quickly made a dummy DLL to limit the problem to the essentials.
>
> Great idea. A more generic example is attractive for people to
> examine and help out.
> I browsed the code but I'm sorry it needs a deeper expertise than I have.
> Hopefully someone working on the threaded FFI will tune in.
>
> In the meantime, it won't solve your query but you may find this
> interesting to watch...
> Strategies for Non-Blocking FFI
> https://www.youtube.com/watch?v=L_QFwsNOMAc
>
> cheers -ben
>
> >
> > I think my problem comes more from how I use the semaphore.
> >
> > I wanted to do that:
> >
> > only "semaphore signal",
> > But that somehow doesn't work.
> > Now i'm doing that "[ Processor yield. semaphore signal ] fork" (it work's)
> > but i don't know if that's a good idea.
> >
> >
> > ffiCallback
> > ^ FFICallback signature: #( void #( uint32 foo ) ) block: [ :foo |
> > Transcript
> > show: 'API Funktion value: ' , foo asString, ' activePriority:',
> > Processor activePriority asString; cr.
> >
> > "that's working"
> > [ Processor yield. semaphore signal ] fork.
> >
> > "that usually works 80%."
> > "[ semaphore signal ] fork"
> >
> > "that crashes pharo almost always."
> > "semaphore signal"
> > ]
> >
> > I also have a little problem, too. Why can I use my own C-Type UNUM32 at
> > ...self ffiCall: #( T_ERROR StartMyThreadFunction(UNUM32 millisecondsToFire)
> > ).
> > But with FFICallback signature: # (void # (uint32 foo)) I get an error
> > "Unable to resolve external type: UNUM32. Why is that?
> >
> > Thanks for your help.
> >
> > testDllForAsyncCallback.dll
> > <http://forum.world.st/file/t372350/testDllForAsyncCallback.dll>
> > testDllForAsyncCallback.cpp
> > <http://forum.world.st/file/t372350/testDllForAsyncCallback.cpp>
> > testDllForAsyncCallback.h
> > <http://forum.world.st/file/t372350/testDllForAsyncCallback.h>
> > testDllForAsyncCallback.h
> > <http://forum.world.st/file/t372350/testDllForAsyncCallback.h>
> > UFFICallback.st <http://forum.world.st/file/t372350/UFFICallback.st>
> > CTypes.st <http://forum.world.st/file/t372350/CTypes.st>
> > <http://forum.world.st/file/t372350/Transcript.png>
> >
> >
> >
> >
> > --
> > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> >
>

--
Pablo Tesone.
[hidden email]

ASAM

Re: UFFI asynchronous callbacks

Hi Pablo,
today I have a little bit of time to try out the "threaded FFI".
But immediately with the load I get the following error message
"PrimitiveFailed: primitive #primitiveInitializeQueueWith: in
TFCallbackQueue failed".

see pic: <http://forum.world.st/file/t372350/ThreadedFFI.png>

When I load it again it looks good. But then I get the error message with
every Pharo start.

To rule out possible errors, I tested with a fresh Pharo8 64bit image, of
course.

Could you tell me what i'm doing wrong?

Thanks
ASAM

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Ben Coman

Re: UFFI asynchronous callbacks

Could you provide the actual code you are running?

On Sat, 25 Jul 2020 at 16:17, ASAM <[hidden email]> wrote:

>
> Hi Pablo,
> today I have a little bit of time to try out the "threaded FFI".
> But immediately with the load I get the following error message
> "PrimitiveFailed: primitive #primitiveInitializeQueueWith: in
> TFCallbackQueue failed".
>
> see pic: <http://forum.world.st/file/t372350/ThreadedFFI.png>
>
> When I load it again it looks good. But then I get the error message with
> every Pharo start.
>
> To rule out possible errors, I tested with a fresh Pharo8 64bit image, of
> course.
>
> Could you tell me what i'm doing wrong?
>
> Thanks
> ASAM
>
>
>
>
>
>
>
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>

ASAM

Re: UFFI asynchronous callbacks

no code is needed as I mentioned ...

.... But immediately with the load

Metacello new
baseline: 'ThreadedFFI';
repository: 'github://pharo-project/threadedFFI-Plugin';
onConflictUseLoaded;
load.

To rule out possible errors, I tested with a fresh Pharo8 64bit image, of
course.

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

tesonep@gmail.com

Re: UFFI asynchronous callbacks

In reply to this post by ASAM

Hello,
for executing it you will need the headless VM. If you are using
Pharo Launcher you can change the VM for that image in the
configuration combo box (The click on "Edit Configurations..."). If
you are using the zero-conf you can use "wget -O -
get.pharo.org/64/vmHeadlessLatest90 | bash"

Cheers,
Pablo

On Sat, Jul 25, 2020 at 10:17 AM ASAM <[hidden email]> wrote:

--
Pablo Tesone.
[hidden email]