hook all function calls to a class

[Wazza]

HI all, Hope this day is going well.

If someone would care to add there $0.02 too a problem I am facing I
would be very happy.

My problem; I have a class, (lets call it) FooBar, and because it does
a lot of funny interopts with various com instances it is esential
that all calls made in my class to these com instances hapen on the
same thread that created the comm instance.

Unfortunatly for me my aplication is heavily multi threaded and I have
several classes like foobar.

I would like to create a class that inherits foobar, CooBarMk2 that
adds an execution thread that is static to the class; This execution
thread would handle creating the com object and calls to the object.

I would then like to have all calls to the CooBarMk2 class
autotmaticaly be hijacked and pumped to the execution thread to;

I want to do this hijacking (hooking/thunking) because it is not to
feasable to write inherited versions of every member in foobar, as
foobar changes often. From a software maintenece prespecttive, in my
situation, it will cause problems.

The idea is I have a few classes like foobar that change often and I
want a drop in dynamicly created wrappers that will transform them to
my owner threaded needs.

I have done similar things in c++, and it wasn't pretty. But Im not
savy with all the CLR stuff and dynamic code generation features.

Well any thoughts appreciated,

-Wazza

 

[Peter Duniho]

HI all, Hope this day is going well.

If someone would care to add there $0.02 too a problem I am facing I
would be very happy.

My problem; I have a class, (lets call it) FooBar, and because it does
a lot of funny interopts with various com instances it is esential
that all calls made in my class to these com instances hapen on the
same thread that created the comm instance.

Unfortunatly for me my aplication is heavily multi threaded and I have
several classes like foobar.

I would like to create a class that inherits foobar, CooBarMk2 that
adds an execution thread that is static to the class; This execution
thread would handle creating the com object and calls to the object.

I would then like to have all calls to the CooBarMk2 class
autotmaticaly be hijacked and pumped to the execution thread to;

I want to do this hijacking (hooking/thunking) because it is not to
feasable to write inherited versions of every member in foobar, as
foobar changes often. From a software maintenece prespecttive, in my
situation, it will cause problems.

I'm pretty sure what you're asking about can be done. But I'm just as
sure that "from a software maintenance perspective", doing it that way
will be much more problematic than just doing it the tedious way.

Trying to dynamically rewrite the classes so that method calls are
redirected through some cross-thread invocation is going to be fragile,
possibly version dependent, and very complicated.

On the other hand, your scenario is basically exactly the same as any
multi-threaded Forms or WPF application. And somehow, all of those
developers who write those multi-threaded Forms or WPF applications
manage to successfully handle the cross-thread issues without an
invasive call-redirection infrastructure.

The idea is I have a few classes like foobar that change often and I
want a drop in dynamicly created wrappers that will transform them to
my owner threaded needs. [...]

It seems to me that if you don't want all the client code dealing with
cross-thread issues, the more correct, more maintainable approach would
be to write managed wrappers for the COM objects that just always
marshal calls to the correct thread for that COM object. You'll have to
replicate the API the COM object exposes, but you'll only have to do
that once for each COM object. Then you can just use the managed object
instead of the COM object.

Doing it that way, you can also start with a base class that contains
the underlying thread and invocation implementation, and reuse that for
each of the COM wrappers. Contrast that to your other suggestion, in
which each "wrapper" _inherits_ an already-existing class without that
functionality. That means at best, you'll have to reuse the code
through composition, and any API that's specific to that implementation
will have to be copied-and-pasted into each subclass wrapper.

I think that would be much better to either just live with the
requirement that cross-thread calls need explicit marshaling, or create
a base class for COM wrappers that supports that and then implement the
wrapper methods for each COM object to do the cross-thread marshaling,
than implementing something that dynamically rewrites existing classes.

That's my two cents.

Pete

 

[Wazza]

Indeed, and that is the way I (and most good programmers) have
approached such things for all the reasons you specified and more.
However today I must walk a darker path in a unusual situation (now
that's a flowery way to say awful hack).

To be blunt I am looking to create a complicated and ugly hack that
will shoe-horn some code together In a situation where a giant legacy
aplication needs to use poorly written 3rd party (opensource) com
classes (that are more than just com wrappers) . As with many things
in legacy aplications refactorinf code bases is not always possible
(due to time constraints) and I dont wnat a wrapper that needs
updating when we adopt a newer version of our dependency code (yes its
odd but we have some code depenencies which we keep in code form for
the sake of minor alterations and compiling 32 and 64 bit binaries).

If I had to worry about long term software maintence I would not do
this. Fortunatly the aplication is for a scientific endevour that will
reach its conclusion soon (there is only another 6 to 12 months of
maintainence before the code is abandonded).

Again version and system dependence is not an issue as the code only
runs on a few machines and is is not sold to anyone (Man I love my
job),

So in essence I am aware that This is both an ugly and complicated
idea, But this is a ugly and complicated situation and I am an ugly
and complicated kinda person... And I want to know something about the
technical feasability of my proposal and how I might go about it.

-Wazza

HI all, Hope this day is going well.

If someone would care to add there $0.02 too a problem I am facing I
would be very happy.

My problem; I have a class, (lets call it) FooBar, and because it does
a lot of funny interopts with various com instances it is esential
that all calls made in my class to these com instances hapen on the
same thread that created the comm instance.

Unfortunatly for me my aplication is heavily multi threaded and I have
several classes like foobar.

I would like to create a class that inherits foobar, CooBarMk2 that
adds an execution thread that is static to the class; This execution
thread would handle creating the com object and calls to the object.

I would then like to have all calls to the CooBarMk2 class
autotmaticaly be hijacked and pumped to the execution thread to;

I want to do this hijacking (hooking/thunking) because it is not to
feasable to write inherited versions of every member in foobar, as
foobar changes often. From a software maintenece prespecttive, in my
situation, it will cause problems.

I'm pretty sure what you're asking about can be done.  But I'm just as
sure that "from a software maintenance perspective", doing it that way
will be much more problematic than just doing it the tedious way.

Trying to dynamically rewrite the classes so that method calls are
redirected through some cross-thread invocation is going to be fragile,
possibly version dependent, and very complicated.

On the other hand, your scenario is basically exactly the same as any
multi-threaded Forms or WPF application.  And somehow, all of those
developers who write those multi-threaded Forms or WPF applications
manage to successfully handle the cross-thread issues without an
invasive call-redirection infrastructure.

The idea is I have a few classes like foobar that change often and I
want a drop in dynamicly created wrappers that will transform them to
my owner threaded needs. [...]

It seems to me that if you don't want all the client code dealing with
cross-thread issues, the more correct, more maintainable approach would
be to write managed wrappers for the COM objects that just always
marshal calls to the correct thread for that COM object.  You'll have to
replicate the API the COM object exposes, but you'll only have to do
that once for each COM object.  Then you can just use the managed object
instead of the COM object.

Doing it that way, you can also start with a base class that contains
the underlying thread and invocation implementation, and reuse that for
each of the COM wrappers.  Contrast that to your other suggestion, in
which each "wrapper" _inherits_ an already-existing class without that
functionality.  That means at best, you'll have to reuse the code
through composition, and any API that's specific to that implementation
will have to be copied-and-pasted into each subclass wrapper.

I think that would be much better to either just live with the
requirement that cross-thread calls need explicit marshaling, or create
a base class for COM wrappers that supports that and then implement the
wrapper methods for each COM object to do the cross-thread marshaling,
than implementing something that dynamically rewrites existing classes.

That's my two cents.  

Pete