Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 10 Apr 1999 00:45:26 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        dot@dotat.at (Tony Finch)
Cc:        smp@FreeBSD.ORG
Subject:   Re: concurrent select()s on listen socket broken under SMP
Message-ID:  <199904100045.RAA05886@usr01.primenet.com>
In-Reply-To: <E10VZGo-0006yj-00@fanf.noc.demon.net> from "Tony Finch" at Apr 9, 99 12:16:22 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> >The basic reason behind this is (aside from the non-standard behaviour and
> >fairness issues) is that select() can notify a process that multiple
> >sockets are ready to be dealt with, while a process will probably only be
> >able to deal with one at a time.
> 
> thttpd deals with all the ready descriptors between calls to select()

I think it is bogus to put the code to deal with this problem into
each and every user space application, just like I think the Apache
hacks to alarm out of shutdown(2) and call close(2) and expect the
close(2) (which implies a shutdown(2)) to break things out of the
FIN_WAIT_2 state to deal with what is an obvious design error (one
packet out, two packets in response, just like Window SMB and NetWare
NCP file locks).

It's on the order of bogosity of having a link manager that can't
base link up/down decisons on who's generating the traffic, or
having to bind sockets to IP addresses in order to bind them to
an interface, such that every time the IP address changes, you
have to restart your daemons.  Bletch.  Poor design is poor design.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904100045.RAA05886>