Jaromir Dolecek <jdolecek@NetBSD.org>  wrote:
 > Matt Thomas wrote:
 > > If connect succeed with any backpressure (as is the default 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.  If you make the connect sleep until accepted, you can limit the
 > > overruns.   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.
 > 
 > This sounds reasonable and I don't see any API incompatibility
 > in this. Everyone agrees that connect() can block, right?
 > What exact API incompatibility you are referring to, Perry?
 > Doesn't postfix do something stupid such as assuming connect
 > to AF_LOCAL won't block?
 > 
 > Of course, the clients should only be put to sleep if the
 > socket is open in blocking (default) mode. Does your code
 > work this way, Matt?


Looks like one can build postfix with this:

	#ifdef UNIX_DOMAIN_CONNECT_BLOCKS_FOR_ACCEPT
	     
	/* qmgr_transport_connect - handle connection request completion */
		
	static void qmgr_transport_connect(int unused_event, char *context)
	{   
	    QMGR_TRANSPORT_ALLOC *alloc = (QMGR_TRANSPORT_ALLOC *) context;
	    
	    /*
	     * This code is necessary for some versions of LINUX, where connect(2)
	     * blocks until the application performs an accept(2). Reportedly, the
	     * same can happen on Solaris 2.5.1.
	     */
	    event_disable_readwrite(vstream_fileno(alloc->stream));
	    non_blocking(vstream_fileno(alloc->stream), BLOCKING);
	    event_enable_read(vstream_fileno(alloc->stream),
			      qmgr_transport_event, (char *) alloc); 
	}                       
	 
	#endif

I haven't succeeded in making /usr/pkgsrc/mail/postfix actually start
up as an alternate postfix on my affected server so I haven't confirmed
yet.