>> Could you please elaborate on the need?
> If connect succeed with any backpressure (as is the default
("without", surely?)
> behavior), then it quite easy for a swarm of requests to overwhelm an
> accepting server since his backlog can be exceeded before he even
> gets scheduled to run.

This can happen even with block-until-accept behaviour; it just takes
lots of processes.  Which is probably what you would have anyway; how
often does a single process connect to the same server again before
carrying out whatever protocol the first connection is intended for?

> If you make the connect sleep until accepted, you can limit the
> overruns.

Only by the number of client processes.  And even then, only if the
clients are using blocking-mode connects; if the clients are using
nonblocking connects, you are either breaking nonblocking connect
semantics or not helping any.

> Part of the problem is that when the backlog is exceeded the error is
> ECONNREFUSED.  This makes it impossible for a client to determine
> whether it was because there was no socket bound to the right name or
> that socket accept queue became full.

Right.  So maybe the right thing to do is to fix that.  Or increase the
silent hard limit on listen queue length.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B