COM again - the need for run-time error checking
In my earlier post about embedded COM, I failed to mention one of the main motivations: dynamic linking.
In embedded systems resources are constrained. So overheads are kept low. Component models that use static linked libraries tend to be simpler, and so have been preferred in the embedded world (not that component models have yet proven all that popular in embedded systems anyway).
Also, static linked models let the compiler check for depenedencies - for instance detecting if a required component is in fact not present.
So a dynamic linked model (like COM) suffers from greater overheads, and also from more likely run-time errors due to requested component not in fact being there.
The first (overhead) can be limited by adopting only a subset of COM - and is a prime reason for not following Microsoft into .NET which has a much bigger run-time system overhead due to the greater sophistication of the .NET run-time library.
The second (run-time errors) requires programmers to properly hndle errors such as a requested interface not being found, at run time. So it makes the application code that much harder to write. But without dynamic linking then we would not be able to put together systems at run time - they would always have to be compiled and that is not quite a 'component' model where we can litrally 'plug together' components to make a system.
If we do choose COM (and to support dynamic linked components) then we need to take a lot of care in error handling - which leads me to think that error handling is going to be an important topic in my new training classes that deal with component architectures and especially with COM.
In embedded systems resources are constrained. So overheads are kept low. Component models that use static linked libraries tend to be simpler, and so have been preferred in the embedded world (not that component models have yet proven all that popular in embedded systems anyway).
Also, static linked models let the compiler check for depenedencies - for instance detecting if a required component is in fact not present.
So a dynamic linked model (like COM) suffers from greater overheads, and also from more likely run-time errors due to requested component not in fact being there.
The first (overhead) can be limited by adopting only a subset of COM - and is a prime reason for not following Microsoft into .NET which has a much bigger run-time system overhead due to the greater sophistication of the .NET run-time library.
The second (run-time errors) requires programmers to properly hndle errors such as a requested interface not being found, at run time. So it makes the application code that much harder to write. But without dynamic linking then we would not be able to put together systems at run time - they would always have to be compiled and that is not quite a 'component' model where we can litrally 'plug together' components to make a system.
If we do choose COM (and to support dynamic linked components) then we need to take a lot of care in error handling - which leads me to think that error handling is going to be an important topic in my new training classes that deal with component architectures and especially with COM.
Comments
Post a Comment