Could External Functions use named libraries?
Kevin Powick
DEFFUN name {(arg1 {, arg2 ...})} EXTERNAL {libname}
If "libname" is not given, then default to qmextcall/qmextcall.exe
--
Kevin Powick
Ashley Chapman
Even cooler would be to allow QM to call native DLL functions from any DLL that you know the interface of. Things such as the Windows API. OpenInsight allows this, and on the systems that I've seen it's a hugely useful facility.
Yes I know that it would be Windows specific, but boy would it be great!
Take a look here:-
http://sprezzblog.blogspot.co.uk/2009/06/dll-prototyping-strings-and-things-part.html
http://sprezzblog.blogspot.co.uk/2009/09/dll-prototyping-strings-and-things-part.html
http://sprezzblog.blogspot.co.uk/2009/09/dll-prototyping-strings-and-things-part_15.html
And if QM was to have it implemented in the same way that OpenInsight does it would be a double bonus :)
Ashley
Martin Phillips
Hi Ashley/Kevin,
Long ago, Doug Dumitru developed a feature for QM that allowed calls to external functions so long as they had relatively simple interfaces. This was done specifically for use in Coyote and I was very concerned that it exposed the managed environment of QM to damage by mis-use or coding error. If the shared memory was corrupted, the effect could even be damage to a file that was being used only by some other process, making things very hard to debug. Somewhere along the way, Doug did indeed manage to overwrite a system file.
What was needed was a way to protect the managed environment whilst still allowing calls to useful external subroutines. This requires that the process memory is safe, files open to the QM process cannot be directly accessed by the external code, and system resources such as semaphores are isolated. The only practical way to do this is to use the child process concept that the External Call Interface added recently uses.
We went through a few iterations of this in early experiments. Our first idea was to allow the child process to dynamically link to any DLL or shared object library by defining the external function using both the library and entry point name. We took this further by defining the external functions using something very much like a C declaration and doing all the argument passing automatically based on this. Our prototype of this worked ok on Windows but we found a few problems with generalising this on Linux that set us off looking for an alternative. The complexities added by needing it to work for all combinations of 32/64 bit, big/little endian and ECS/ASCII don’t help. It is worth noting, however, that there is no reason why dynamic linking could not still be adopted within the structure that we have put in place. It does not require an alternative name for qmextcall or any change to the interface between the child and parent processes. The child process is there purely to interface to the called function whilst protecting the QM session. The library and function name can be passed as a single string (e.g. “library:function”) and the function interface prototypes can be compiled into a file accessed by the child process.
It is possible (likely?) that we will revisit this in the future to see if we can publish the source form of a qmextcall program that supports dynamic linking by library and function name. The current implementation is intended to meet the immediate needs of users who have requested this capability. In most cases, QM provides native alternatives to application use of underlying libraries and we are always open to suggestions of new capabilities.
The way in which OpenInsight handles external function calls is, quite reasonably, very much mirroring Windows API style and may not map easily onto Linux. I also suspect, though I have not checked, that it does the calls in-process and hence exposes the process to the sort of problems discussed in my first couple of paragraphs.
Your comments are appreciated and will be considered in more details if/when we revisit the idea of dynamic linking.
Martin
Kevin Powick
On Thursday, 16 May 2013 04:26:16 UTC-4, Martin Phillips wrote:
What was needed was a way to protect the managed environment whilst still allowing calls to useful external subroutines. This requires that the process memory is safe, files open to the QM process cannot be directly accessed by the external code, and system resources such as semaphores are isolated. The only practical way to do this is to use the child process concept that the External Call Interface added recently uses.
Martin Phillips
Hi Kevin,
I accept your point about not being able to run multiple external call interface processes. This has been added to the wish list for investigation. I cannot immediately see why it would be a problem.
Martin
--
You received this message because you are subscribed to the Google Groups "OpenQM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openqm+un...@googlegroups.com.
To post to this group, send an email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openqm?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
Kevin Powick
On Thursday, 16 May 2013 11:18:56 UTC-4, Martin Phillips wrote:
I accept your point about not being able to run multiple external call interface processes. This has been added to the wish list for investigation. I cannot immediately see why it would be a problem.