[omniORB] omniorbpy patch for new style python objects

[Alastair Tse]

On 15 Dec 2005, at 12:15, Duncan Grisby wrote:
>> Since Python 2.3, the threading.Thread class in python (and many
>> others) are new style objects. That means the inherit from the
>> "object" class rather than no class at all.
>
> I think it's a very bad idea to derive servant classes from
> threading.Thread. It confuses to unrelated sets of functionality. One
> day it might cause your code to fail if either omniORB or the  
> threading
> module change in some way.

I don't quite see why mixing the two is a bad idea. Maybe because I  
don't understand the internals of how omniORB works very well. I  
suppose you are suggesting that I should just have an instance of the  
servant inside a thread rather than subclassing from it because they  
might conflict with each other in interesting ways?

And yes, it has broken for us once, and hence the patch to support  
new style objects. That is the only change after 2 years of running  
this code, although it is only a very small part of the code base,  
but by far the most complicated bit because of the fact that I have  
to manage the possibility of many spawned servant instances.
>
> I don't want to integrate your patch to omniORBpy 2 because it's a
> fairly major change. It also looks like it will be incompatible  
> with old
> Python versions, and will have a performance impact.
>

No problems. I just wanted an opinion about the patch. But thank you  
for your comments as I didn't realise that there was a no-no that I  
was committing with threads and servants.

Cheers,

Alastair

--
Alastair Tse
PhD Student, LCE, Computer Lab, University of Cambridge
[Tel] +44 1223 767 017  [Mob] +44 7795 973639
[Web] http://www.cl.cam.ac.uk/Research/DTG/~acnt2/