Re: [Pharo-users] UFFI asynchronous callbacks

[teso...@gmail.com]

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  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:  
>
> 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
>


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-users] UFFI asynchronous callbacks

[ASAM]

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

Re: [Pharo-users] UFFI asynchronous callbacks

[Ben Coman]

Could you provide the actual code you are running?

On Sat, 25 Jul 2020 at 16:17, ASAM  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:  
>
> 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
>

Re: [Pharo-users] UFFI asynchronous callbacks

[ASAM]

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:   

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

Re: [Pharo-users] UFFI asynchronous callbacks

[teso...@gmail.com]

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  wrote:
>
> Hi Asam,
>
> On Sun, 19 Jul 2020 at 21:38, ASAM  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
> > 
> > testDllForAsyncCallback.cpp
> > 
> > testDllForAsyncCallback.h
> > 
> > testDllForAsyncCallback.h
> > 
> > UFFICallback.st 
> > CTypes.st 
> > 
> >
> >
> >
> >
> > --
> > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> >
>


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-users] UFFI asynchronous callbacks

[Ben Coman]

Hi Asam,

On Sun, 19 Jul 2020 at 21:38, ASAM  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
> 
> testDllForAsyncCallback.cpp
> 
> testDllForAsyncCallback.h
> 
> testDllForAsyncCallback.h
> 
> UFFICallback.st 
> CTypes.st 
> 
>
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>

Re: [Pharo-users] UFFI asynchronous callbacks

[ASAM]

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
  
testDllForAsyncCallback.cpp
  
testDllForAsyncCallback.h
  
testDllForAsyncCallback.h
  
UFFICallback.st   
CTypes.st   
 




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

Re: [Pharo-users] UFFI asynchronous callbacks

[Ben Coman]

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  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
>
>