suspend/resume in trouble...

[Poul-Henning Kamp]

In message <ujrirq5xud9.fsf at cat.linpro.no>, Dag-Erling =?iso-8859-1?Q?Sm=F8rgra
v?= writes:

>However, there's a significant chance this may break existing
>applications which expect listen(0) to be equivalent to
>listen(SOME_IMPLEMENTATION_DEFINED_NON_ZERO_VALUE).  It's also very
>hard to test for in a configure script.  Therefore, it's probably
>simpler to add an unlisten() syscall.

I would probably go for listen(-1) instead.  Adding a syscall
is a major pita, and if you do unlisten(2) on a socket, does
that mean you can connect(2) it then ?

listen(-1) should be trivial to test for in autoconf.

>On systems which lack unlisten(), a suspended server can simply reply
>to any incoming connections with 503 Service Unavailable, without even
>bothering to look at the request.

But that sort of defeats the entire purpose behind suspend/resume:
to let the load-balancer front-end discover that we're not answering.

I would say:

if system offers listen(-1):
	suspend / resume works as advertised.
else
	suspend is not implemented
	resume works only once.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.