hodgesse1 / rfortran

Automatically exported from code.google.com/p/rfortran
0 stars 0 forks source link

Robust handling of multiple clients on single COM channel #51

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
*** 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

GoogleCodeExporter commented 8 years ago
A semi-permanent solution to this problem is provided in v2.0.0

Original comment by mark.th...@gmail.com on 19 Feb 2010 at 5:32