I'm not really sure what to do with this report. Is there something that the BGE is or isn't doing that causes this problem? In other words is it a Python issue or a BGE issue?

First of all I apologize for my poor English.

The problem arises only when you use the library python "concurrent.futures" within blenderplayer, in fact the import and use of the library inside blender not pose any problems, there is no problem in using this library outside of blender as pure python scripts.
In fact, the library itself works without any problem.
The methods registered by atexit inside the library "concurrent.futures" create problems with atexit registered by blenderplayer.

I apologize if I used the tag incorrectly.
I remain at your disposal.

um, I re-read what I wrote and I have found it incomprehensible this time too. Sorry.
Short answer I think it is a problem of bge.
The atexit used whitin bge should not create problems with the python standard libraries.
Sorry again. I need some sleep.
I remain at your disposal, Giulio.

As far as I can tell, the Blenderplayer doesn't mess with Python's atexit...

I'm guessing there is something the the Blenderplayer needs to do (some Python C API call, but I don't know what it is). Campbell, do you know anything about this?

This is caused (I believe) by the main thread exiting before the other threads close, so all references become None.
I have the same *issue* in my multi-player system which spawns threads.

To try fixing this, close the BGE yourself using an ESC key sensor, and do the following:

http://www.pasteall.org/51192/python

I'm not seeing an error with the supplied test file (I'm using the Blenderplayer).

That's because (IIRC) of how the BGE finishes with the Python environment when the internal player exits. It shouldn't exist in the external player (I don't think)

@Mitchell Stokes (moguri)
"I'm not seeing an error with the supplied test file (I'm using the Blenderplayer)."

Well, this is getting triky! What version of blenderplayer are you using? Which OS?
I'm using blender released by irie ppa, on Mint 13 LTS.
Well I’m waiting for next Mint release based on 14.04 to upgrade my OS.
I had the same error on debian testing, which is the OS that is using a friend of mine.
I still have not been able to test the code on a Windows machine...

@Angus Hollands (agoose77)
"To try fixing this, close the BGE yourself using an ESC key sensor, and do the following"

Ok, this is working well. With your workaround i can use concurrent.futures on my code. Good!
I was already using a ESC key sensor for free the resources and killing the threads on my project.
I also implemented the signals handling to release the resources, given that the project that I am developing is meant to be launched via ssh into a remote machine, and yes, i am aware that the functions registered with atexit are not performed if the program is killed by a signal is not handled by the python code.
(see https://docs.python.org/3.3/library/atexit.html)
However, explicitly call the atexit function it is not the purpose for which the function has been designed for.
"..function registered are automatically executed upon normal interpreter termination" (python doc)
Well in my environment, only the import library "concurrent.futures" generates the error on atexit.

"That's because (IIRC) of how the BGE finishes with the Python environment when the internal player exits. It shouldn't exist in the external player (I don't think)"

I understand what you're saying.. i get the same problem when i switch scene in blender project (sig).
In any case, in my code I have to get tons of OSC messages from UDP socket, which is set in blocking mode: I need threads.
Thanks agoose77, you've been a great help.
I put the code that I mentioned before, purged by the OSC parser.
Sorry for the tabs in the code, it is an old habit... (see test2.zip)

Ps.
I got segmentation fault when i lunched the game engine inside blender using the project "

I remain at your disposal. Giulio

(edit reason: my english sucks...)

I am using Arch Linux 64bit, and a version of the Blenderplayer built from master. Maybe the switch to Python 3.4 fixed something?

I received an update via irie blender ppa...
Blnder now uses python 3.4 and I no longer have the error that I pointed out!

Great!
Whatever the problem was, it was solved by changing the version of python.

Thank you all for the help.

Giulio