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 <b...@openinworld.com> wrote: > > Hi Asam, > > On Sun, 19 Jul 2020 at 21:38, ASAM <vmax28...@gmail.com> 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. teso...@gmail.com
