Ruby and CLR interactions

[John Lam]

While building my Ruby <-> CLR shim, I came across a nasty issue with
respect to initializing the CLR in a delay-load scenario.

In existing versions of the CLR (< 2.0), COM is not guaranteed to be
initialized. Most of the time it isn't, which is why all of the existing
Ruby <-> CLR bridges can call CoInitializeEx via
Thread.ApartmentStatewithout potentially breaking something. However,
there are some (rare)
scenarios where the CLR will initialize COM prior to the Ruby bridge being
called, which will hose folks who were attempting to change the
ApartmentState in their Ruby scripts (or in their bridge).

The Whidbey (V2.0) version of the CLR forces all threads into the MTA by
default - this gets rid of the indeterminate behavior of earlier versions of
the CLR. This currently will hose anyone using any of the existing bridges,
unless you jump through some exotic hoops. Once I release the source for my
bridge, you'll see what those exotic hoops look like. If any of the existing
bridge maintainers want to know the specifics, please feel free to ask away

[Wayne Vucenic]

Hi John,
I'm really glad to see that someone is working on a shim for CLR 2.0!

>> But if I don't initialize
>> the CLR until after my Ruby program has already started running, I'm
going
>> to run into some nasty corner cases. For example, what if someone called
a
>> COM object via win32ole? By the time we get to my shim, COM will have
been
>> initialized already and there's not a lot I can do other than fail when I
>> attempt to initialize COM again.

>> I was wondering if folks would have some ideas about *how* I can declare
my
>> threading requirements at startup time?
I'm not sure I'm clear on when you need to declare the threading
requirements.
Would doing something like this as the first 2 lines in the .rb file work?
require 'clrshim'
setSTA
where 'setSTA' (or 'setMTA') is a method your shim defines.
as long as any win32ole stuff came after this, we should be OK.
Or am I overlooking something?
Wayne Vucenic
No Bugs Software
"Ruby and C++ Agile Contract Programming in Silicon Valley"

[John Lam]

Hi Wayne,

>> I'm really glad to see that someone is working on a shim for CLR 2.0!

Me too :)

>> Would doing something like this as the first 2 lines in the .rb file
work?
>> require 'clrshim'
>> setSTA

The problem is that require 'rubyshim' would have to be guaranteed to be the
first line of code in a *program*. I'm not sure at all how I can make that
guarantee given the semantics of require.

So hence my thinking around doing a platform-specific change to the Ruby
runtime to check for a configuration file.

-John

[Wayne Vucenic]

Hi John,
I think I understand your concern.
Suppose I have a file called clrstuff.rb, which uses the CLR shim. The
apartment model gets set up correctly, and everything works fine.
Now someone writes a file, foo.rb, which uses win32ole, then does a
"require 'clrstuff'". But win32ole may have set up an incompatible apartment
model before 'clrstuff' gets invoked, which causes problems for 'clrstuff'.
Is this basically the problem?
I believe your proposal is to put some info on the required configuration
into foo.rb.config. I assume you're proposing a separate file to handle the
case where we're unwilling/unable to simply make the changes directly to
foo.rb.
It seems like this would work, and I can't right off think of a
substantially different approach. It's unfortunate that the configuration
file needs to be attached to foo.rb rather than to clrstuff.rb. This way
when the file bar.rb comes along which uses win32ole and then requires '
foo.rb', we'll also need a bar.rb.config.
I'd like to suggest a slight modification/generalization to your proposal.
I'd suggest supporting two files, with names like foo.rb.pre and foo.rb.post.
Both files contain ordinary Ruby code, but ".pre" is run before foo.rb and
".post" is run after. .pre can be used to do what your .config file would
do. .post would be useful when foo.rb contains a buggy method and for
whatever reason I can't change foo.rb. Then I can redefine the problematic
method in .post.
Wayne

[Tanner Burson]

[John Lam]

Hi Tanner,

>> ruby -rclrshim $1

I really like your *simple* solution to this problem. There are still some
corner cases (like what if someone doesn't call the wrapper?)

But it's more than good enough, and let's me refocus my attention on the
hard parts of building the shim.

Thanks for the suggestion.
-John