The CLR always loads up ole32 at startup and will even if it didn't it'd need
to for the [STAThread] attribute.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William Reade
Sent: Friday, November 07, 2008 4:03 AM
To: Discussion of IronPython
Subject:
Thanks Dino -- you've given me plenty to be going on with until you hear
back from the CLR dev.
Dino Viehland wrote:
In MTA mode we'll create a new thread which is thread 3 - thread 1 will just be
hanging around waiting for it to exit. Unfortunately w/o a separate EXE we
can't avoid the
So far as I can tell, CPython ctypes and installers (neither of which
are currently relevant) use COM, and numpy doesn't use it at all.
However, my search wasn't very sophisticated -- I just looked for
CoInitialize, CoCreateInstance, and lpVtbl, which is all the COM I can
remember*. Was that
I'll look into that along with everything else :).
Dino Viehland wrote:
Do you know if numpy is using COM anywhere? Or does Ironclad use COM for any
of its interop?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William Reade
Sent: Thursday,
Thanks Dino -- it seems that if I use ipy with -X:MTA, I can no longer
reproduce the problem. However, this bothers me a bit: I'm not competent
to follow all the consequences here, but this situation seems to imply
that Ironclad won't be usable safely from any STA thread. Is this an
intended
When you run with -X:MTA, is the object now being finalized on a thread
other than thread #2?
On Thu, Nov 6, 2008 at 7:01 AM, William Reade
[EMAIL PROTECTED]wrote:
Thanks Dino -- it seems that if I use ipy with -X:MTA, I can no longer
reproduce the problem. However, this bothers me a bit: I'm
Finalization still happens on thread 2, and I see no evidence of thread
1 any more; my main thread now appears to have id 3.
Curt Hagenlocher wrote:
When you run with -X:MTA, is the object now being finalized on a
thread other than thread #2?
On Thu, Nov 6, 2008 at 7:01 AM, William Reade
In MTA mode we'll create a new thread which is thread 3 - thread 1 will just be
hanging around waiting for it to exit. Unfortunately w/o a separate EXE we
can't avoid the separate thread.
I've pinged the CLR dev who owns interop these days to see if he's ever seen
anything like this.
Do you know if numpy is using COM anywhere? Or does Ironclad use COM for any
of its interop?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William Reade
Sent: Thursday, November 06, 2008 6:01 AM
To: Discussion of IronPython
Subject: Re: [IronPython]
Hi all
While running the numpy tests, I've come across a situation which, to
the best of my knowledge, is simply impossible. I'm hoping that one of
the local .NET gurus will be able to tell me what I'm missing, or point
me somewhere I can get more insight.
The 4 methods involved are as
Incidentally, logging a Stopwatch timestamp in WriteFlush reveals that,
yes, the calls really are happening in the order they appear to be. So,
option (3) appears to be a red herring, and options (1) and (2) remain
unchanged.
William Reade wrote:
Hi all
While running the numpy tests, I've
So, the obvious question for me is whether or not you're using any
finalizers.
On Wed, Nov 5, 2008 at 5:57 AM, William Reade
[EMAIL PROTECTED]wrote:
Hi all
While running the numpy tests, I've come across a situation which, to the
best of my knowledge, is simply impossible. I'm hoping that
...or, for that matter, any __del__ methods from within Python -- which
ultimately are handled by finalization.
On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher [EMAIL PROTECTED]wrote:
So, the obvious question for me is whether or not you're using any
finalizers.
On Wed, Nov 5, 2008 at 5:57
Hi Curt
I am indeed; that's how I know thread 2 is the GC thread. Is locking
during GC forbidden?
William
Curt Hagenlocher wrote:
...or, for that matter, any __del__ methods from within Python --
which ultimately are handled by finalization.
On Wed, Nov 5, 2008 at 9:37 AM, Curt
Locking during finalization is often considered to be a bad idea. In
particular, locking without a timeout introduces the possibility that you
will hang the finalization thread, preventing further objects from being
finalized. But clearly, that's not what's happening here.
Other questions that
The log starts in the middle (after many lock/unlocks, some from each
thread); I'm running on x86; and I have no additional AppDomains.
I don't think it would be safe for me to entirely avoid locking during
finalization, but I could probably cut it down to a quick lock, on a
separate object,
I would suggest getting a snap shot of the call stacks when this is happening
if that's possible. I can't pin anything down but I wonder if you could have
an STA object or something that otherwise requires message pumping. That
message pumping could happen while you're doing a Monitor.Enter
17 matches
Mail list logo
