*** Please provide a description of the enhancement you are requesting.
Further to a previously posted issue on COM - which as it turns out
under-estimated the complexity of the problem.
Overall, my experimentation over the last few days suggests that COM
connectivity needs to be robustified across all our code.
We need to account for the potentiality (already here with BATEA) of
multiple, potentially concurrent or at least sequential, usage of the
(necessarily single) COM channel by several 3rd party software, not all of
which may properly initialize/cleanup after the(ms)elves.
In particular, there is:
1) software (eg, CAV, IAV) that appears to independently open a COM channel
but not always correctly close it (or may fail to close due to some
internal error).
2) Matlab automation may independently open/close COM servers.
In both these cases the actual internal working are inside proprietary
exe/dll/lib files and hence invisible to us (I had to employ Bayesian
inference to deduce what was going on).
The new DMSL goes some way towards addressing these issues.
I also modded some RFortran files to enable usage within BATEA, but this
makes them incompatible with current structure of RFortran (it requires
access to filepaths_dmsl_kit). Hence I am "hesitant" to commit them without
prior consultation.
I think 100% bullet-proof code is difficult for some extreme cases, but we
should develop some consistent strategy for dealing at least with the
majority of these situations.
Original issue reported on code.google.com by dmitri.k...@gmail.com on 15 Sep 2009 at 2:20
Original issue reported on code.google.com by
dmitri.k...@gmail.com
on 15 Sep 2009 at 2:20