[Errno -3] When using Threading

Hello. There is my example of code I'm using:

```
import threading
import resource
import time
import sys

#maximum Open File Limit for thread limiter.
maxOpenFileLimit = resource.getrlimit(resource.RLIMIT_NOFILE)[0] # For example, it shows 50.

# I will use one session for every Thread.
requestSessions = requests.Session()
# Making the requests Pool bigger.
adapter = requests.adapters.HTTPAdapter(pool_connections=maxOpenFileLimit, pool_maxsize=maxOpenFileLimit, pool_block=True)
requestSessions.mount('http://', adapter)
requestSessions.mount('https://', adapter)

def requestAction(a1, a2):
    global number
    time.sleep(1) # My actions with Requests for each thread.
    print number = number + 1

number = 0 # Count of complete actions

ThreadsActions = [] # Action tasks.
for i in range(100): # I have 100 websites I need to do in parallel threads.
    a1 = i
    for n in range(3): # Every website I need to "GET" in 3 threads
        a2 = n
        ThreadsActions.append(threading.Thread(target=requestAction, args=(a1,a2)))


for item in ThreadsActions:
    # But I can't do more than 50 Threads at once, because of maxOpenFileLimit.
    while True:
        # Thread limiter, analogue of BoundedSemaphore.
        if (int(threading.activeCount()) < threadLimiter):
            item.start()
            break
        else:
            time.sleep(.1)
            continue

for item in ThreadsActions:
    item.join()
```

But I'm getting an error: `HTTPSConnectionPool(host='www.example.org', port=443): Max retries exceeded with url: /page?news-25 (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7fdc5c138b90>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',))`
As I read in issues, it might happens when some socket is stacked in CLOSE_WAIT status. If there are a lot of sockets, for example, because of slow connection or slow servers, the script might go to the point where all the sockets are in CLOSE_WAIT state. I tried to use `max_retries=10`, and got errors about `Too many files openned`. 

How to pause new requests if all the sockets are in CLOSE_WAIT state? Or why I'm getting these errors?


Requests doesn't provide a way to pause making new requests based on the status of sockets. It doesn't see the sockets itself and even so, it couldn't introspect them for that status.

You should try creating a separate session per thread. This is what the [toolbelt](https://github.com/sigmavirus24/requests-toolbelt) does and it should also avoid any situations where the same socket is used for two different requests. (The Session object used to be thread-safe but those tests disappeared and so the guarantees of thread-safety no longer really exist. It's safer to use one session per thread.)


Then what's the purpose of `pool_block=True`? Shouldn't it make some bottleneck when all the sockets are in use? Maybe it safer to use `resp = requests.get` with `resp.close()` to make sure all the sockets are under the script's control?


"Temporary failure in name resolution" corresponds to EAI_AGAIN. There are _many_ possible causes for such an error, not just the number of sockets in CLOSE_WAIT. Have you seen any evidence that this is the actual problem?

Regardless, your code is not going to do quite what you think. You're trying to limit the number of open file handles you get by using getrlimit. However, you aren't actually limiting yourself to that. `pool_connections` is actually the number of connection pools to keep hold of (one per host), and `pool_maxsize` is the maximum number of connections allowed in each pool. That means you're allowing `maxOpenFileLimit**2` sockets. Even if this did do what you want, you'd still run the risk of running out of file descriptors, because you're not allowing for the fact that stdin/stdout/stderr are almost certainly open.

Given that raising the retry limit fixed the problem in temporary name resolution, it's extremely likely that you want to do that and fix your handling of the maximum number of connections.

Regardless, at this time there is no evidence that this is a bug in Requests, so I'm closing this issue. Thanks for the report!