Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#126 Add COM threads wrapper classes

open
nobody
None
5
2013-04-29
2013-04-29
Stefan Schukat
No

COM requires a specific setup for a thread to function correctly.
- Interface passing has to be done by marshaling
- the thread has to be initialized for a specific apartment type
- every create COM object has to be released before the thread has been uninitialized fro COM
- STA thread join has to do message pumping

This handling is tedious and requires specific knowledge. Hence this patch provides wrapper classes which takes care
of the needed environment. These classes have the same interface as the standard threading.Thread classes and could be used
in the same way.

Unit tests are provided using Microsoft Word as COM server.

Discussion

  • Stefan Schukat
    Stefan Schukat
    2013-04-29

    Implementation and tests for COM threads.

     
    Attachments
  • Mark Hammond
    Mark Hammond
    2013-04-29

    Thanks for the patch - in general this new module looks fine. Could you please upload unzipped .patch files - even in cases like these when only new files are created? Ideally, a patch exported by hg would be best so your name etc appears in the checkin. You might like to look into the "queues" extension/feature of hg.

    Also, whenever possible, the tests should not rely on some external tool being installed - eg, Word is not installed on any of my boxes, so these tests can't be run by me. We already have a number of test COM servers in the test suite, so using one of them would be best (explicitly using a CLSCTX flag if, eg, an out-of-process server is necessary)

    Re comthreads.py:
    * All imports should generally be at the top of the file, and there is no need to "del" the symbols. The only exception would be for imports that are only used in rare cases, but it appears that most of the modules will end up being imported by everyone who uses this module, so they should be at the top.

    * All files should end with line-end sequence.

    * One of the docstrings refers to "dSPACE base thread" which doesn't sound right.

    * It would be great if the docstring for the module demonstrates some example usage - ie, how the consumer of this module would use it.

    * For new code, we try and follow pep8 - eg, instance attributes, variable/arg names etc should not start with an upper-case letter and ideally not be camelCase.

    * def join(self, timeout): - it looks to me like the timeout will be "reset" each time a message appears - ie, a message arriving once every second would cause .join(2) to never return?