Description of problem:
Squid doesn't seem to use CLOEXEC flag on opened file descriptors.
Child processes created for url rewriters execute 32k+ close() syscalls after the clone() call and before the execvp() call.
In squid-3.1.10/src/ipc.cc:

240     if (pid > 0) {              /* parent */
241         /* close shared socket with child */
[...] parent code
296     }
297 
298     /* child */
[...] child code.
      A bit later:
381     /* Make sure all other filedescriptors are closed */
382     for (x = 3; x < SQUID_MAXFD; x++)
383         close(x);

32k+ close() calls in each child process take a long time ([12-56] seconds) in Xen PV guests.
Squid re-creates all the url rewriter child processes even for a 'reload' action.

Version-Release number of selected component (if applicable):
squid-3.1.10-1.el6_2.3.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Install Squid in a RHEL6 Xen PV guest running in a RHEL5 Xen host.
2. Configure an external url rewriter and a pool of several processes:
url_rewrite_program /usr/local/bin/my_custom_url_rewriter
url_rewrite_children 24
3. Issue a 'service squid reload'.
  
Actual results:
Squid child processes take a long time to execute the 32k+ * 24 close() calls.
Browsing the Internet from clients configured to use the Squid proxy becomes unavailable for up to one minute.
Configuration changes can not be applied during work hours.

Expected results:
Squid creates file descriptors using O_CLOEXEC.
Squid doesn't need to attempt to close 32k+ FDs in each child process.
'service squid reload' completes quickly even in a Xen PV guest.

Additional info:
syscalls in a Xen PV guest perform slower than in HVM guests or bare metal, which amplifies the impact of poor FD handling in Squid child processes.