The way the fnmatch module uses its regex cache is not threadsafe. When multiple threads use the module in parallel, a race condition between retrieving a - presumed present - item from the cache and clearing the cache (because the maximum size has been reached) can lead to KeyError being raised.

The attached script demonstrates the problem. Running it will (eventually) yield errors like the following.

Exception in thread Thread-10:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/threading.py", line 763, in run
    self.__target(*self.__args, **self.__kwargs)
  File "fnmatch_thread.py", line 12, in run
    fnmatch.fnmatchcase(name, pat)
  File "/home/marc/.venv/modern/lib/python2.7/fnmatch.py", line 79, in fnmatchcase
    return _cache[pat].match(name) is not None
KeyError: 'lYwrOCJtLU'

I guess that a lot of stdlib modules are not thread safe :-/ A workaround is to protect calls to fnmatch with your own lock.

Ok, if that is the attitude in such cases, feel free to close this.

It would be nice to fix the issue, but I don't know how it is handled in other stdlib modules.

It is easy to make fnmatch caching thread safe without locks. Here is a patch.

The problem with fnmatch is that the caching is implicit and a user don't know that any lock are needed. So either the need of the lock should be explicitly documented, or fnmatch should be made thread safe. The second option looks more preferable to me.

In 3.x fnmatch is thread safe because thread safe lru_cache is used.

@serhiy.storchaka: My thoughts exactly, especially regarding the caching being implicit. From the outside, fnmatch really doesn't look like it could have threading issues.
The patch also looks exactly like what I had in mind.

New changeset fe12c34c39eb by Serhiy Storchaka in branch '2.7':
Issue #23191: fnmatch functions that use caching are now threadsafe.
https://hg.python.org/cpython/rev/fe12c34c39eb