Thanks! Given that useful multi-threaded hashing is only available because
of IronPython's lack of GIL I can't complain too much :-)For reference,
here is the issue link:
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=20324
I look forward to the fix in a future release.
On S
Not without looking at the source code...
We want to be at least as thread-safe as CPython, with the exception that we
have no interest in implementing the equivalent of a "global interpreter
lock" :). This particular case is just bad coding on our part. I can't
promise you that there aren't oth
Thanks Curt. I've filed a bug report. It makes me a bit nervous realizing
that it isn't entirely transparent when shared memory/objects are being
used. Normally I would think a local instance of hashlib.md5() would be
thread-safe from other local instances. Is there any documentation of what
ot
I'm going to guess that this is because we use a static instance
of MD5CryptoServiceProvider to do the hashing, something which may not be
thread-safe. It looks like all of the IronPython crypto implementations do
the same thing, so the SHA functions may have a similar issue.
Please file this as a
I get the following error periodically:
Exception in thread Thread-2:
Traceback (most recent call last):
File "C:\Program Files\IronPython 2.0\Lib\threading.py", line 486, in
_Thread__bootstrap_inner
self.run()
File "initial_ingest.py", line 33, in run
md5 = hashlib.md5(contents).hexdi
