Unusual minidom behaviour: Part Deux

[Victor Bazarov]

"Guido van Rossum" <guido at python.org> wrote...
> Martin von Loewis <loewis at informatik.hu-berlin.de> writes:
>
> > "Victor Bazarov" <vAbazarov at dAnai.com> writes:
> >
> > > Further digging led me to the C source module that contained some
> > > comment "this is to prevent two threads from importing the same
> > > module at the same time returning incomplete module" (or something
> > > like that).  I didn't try to comprehend the C source, sorry.
> > > Although it may not be so difficult, I prefer to leave fixing to
> > > those for whom the system is an open book.
> >
> > Even if you didn't understand the source, it would have been nice if
> > you had indicated what source you were looking at; I could not find
> > any occurrence of "this is to prevent" in the entire Python source
> > code.
>
> He's referring to the import_lock variable in import.c.
>
> > > Understanding that Python thread mechanism does not use the OS
> > > thread mechanism
> >
> > This is a misunderstanding: the Python thread mechanism does use the
> > OS thread mechanism
>
> Just under a layer of wrapper APIs.
>
> > > and with all due respect to the creators and contributors, I would
> > > like to ask, "Has anybody experienced similar situation with more
> > > than one thread competing for the same module?"
> >
> > I'm out of context here: a situation similar to what?
>
> The only situation where I've seen this, ironically, is if you attempt
> to import the test module that's designed specifically to test this
> lock, in the interactive interpreter on Windows.
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)

Thank you both for showing some interest.

Let me tell you once more where I experience the error:

The system that tries to use some XML files is written in Python
and is being run from under a Java application.  In the system
something (that looks like a deadlock) happens when two threads
both need to parse (each its own) XML file.  Both call 'parse'
from 'minidom' package, which leads to an attempt to __import__
the xml.sax.expatreader.  Now, the bad news is that the deadlock
doesn't happen when the system is run from a Windows' console,
for example.  Another piece of bad news: it doesn't happed all
the time, it happens in approx 40% of runs.  Another hint: it
doesn't happen if I run Java in Debug mode (with no breakpoints).
But wait, there is more: as soon as the Java app is killed, the
deadlock is resolved and the Python system proceeds ahead as if
nothing has happened.

The questions I have are: has anyone else seen anything of sorts
and where should I look to try to find _why_ this is happening?

I realise that since it only happens while I am running it under
a Java app, Java _may_ be a problem.  But before I begin blaming
Java for all bad things in the world, I'd like to know for sure.

Victor
--
Please remove capital A's from my address when replying by mail