Under Windows7 I’m trying to use AddressOf as stated in Notes of the docs.
The docs example refers to the Mac platform but I’m supposing that the same can be done also on Windows.
The function passed to AddressOf it is a public one defined in a module and the first line of this function does contains: #Pragma X86CallingConvention StdCall
All works as intended when the function it is called from the DLL synchronously with the application:
app calls DLL -> DLL calls the app function using the function pointer returned by AddressOf.
When the function gets called asynchronously by the DLL (as usual for a true callback) the application crashes and the error gets trapped by Windows.
The app function called does nothing special: a simple assignment of a property declared at the App level.
I know that Xojo isn’t thread safe and the internal thread model it is cooperative.
So, as for the conversation title, AddressOf it is of any use on Windows?
The method it is a global one defined in a module and gets called by an external DLL when something (totally unrelated to the app activities) happens.
The call can be considered async and preemptive i.e. I can’t predict when the method gets called.
The fault happens on both console and desktop applications.
Async should be OK.
Preemptively might be an issue.
Callbacks as module methods should be fine since their entry point won’t come & go like a instance vTable entry.
Instance methods could be a problem since the instance could go out of scope or be otherwise destroyed & then a callback tries to access the methods entry point in the vTable that no longer exists. That would be a problem.
Can we assume this behaviour common to all supported platform and not related to Windows only?
There is a way (I think not) to convert an preemptively event to an async one?
[quote=75856:@Maurizio Rossi]Can we assume this behaviour common to all supported platform and not related to Windows only?
There is a way (I think not) to convert an preemptively event to an async one?
Best regards.[/quote]
Can you say what function you’re declaring to that you’re seeing this behavior? or is it a custom DLL that you’re declaring into?
All it is working as expected but not this “async and preemptively” function.
The DLL does some custom communication with external devices.
In some circumstances some devices needs to report back some async events and in this cases the DLL calls a registered callback function i.e. a Xojo method.
So these events are async and preemptively because the DLL creates itself some threads for the communication task.
Also, keep the callback as simple as possible. Nothing that would allocate memory, no calls into the Xojo framework, etc.
At one time I had a plugin for preemptive threading. MBS added similar features. We both dropped it because of the severe limitations on what you could do and the unreliability even when you adhered to those limitations. But for my plugin at least those pragmas had to be at the top of any method called by the thread.
As a work around you might be able to create a callback function that uses Win32 to post a message to be processed by a window in your app. The callback would be called from a preemptive thread, but the message handler would execute normally on the main thread if you use PostMessage. Not sure if you could pull this off in Xojo or if you would have to write/compile a small library with the callback function in it.
As I recall Windows Functionality Suite has sample code and helper methods for setting up a window or control to receive and process messages, so that part can be done in Xojo.
There’d have to be a small library or plugin to deal with punting whatever callbacks are needed to a Xojo thread. Any running Xojo code must be on a Xojo thread and not a pre-emptive thread. Attempts to make Xojo code work on a pre-emptive thread may initially appear to work but will absolutely run into issues down the road.
Joe - would that be true even if the callback function does nothing but declare and call PostMessage?
I ask because even though I dropped the plugin, I never saw problems with preemptively threaded functions that called OS APIs but otherwise didn’t do anything in Real Studio / Xojo, including anything that could trigger memory allocation / deallocation. That seemed to be the one potentially useful thing you could do preemptively.