Date: Tue, 26 Jun 2001 20:37:10 +0200 (CEST) From: Luigi Rizzo <luigi@info.iet.unipi.it> To: FastPathNow@netscape.net Cc: freebsd-net@FreeBSD.ORG Subject: Re: TCPS_HAVERCVDFIN not considering all possible conditions? Message-ID: <200106261837.UAA98582@info.iet.unipi.it> In-Reply-To: <70F9DB7F.6DE86C34.375A6AF3@netscape.net> from "FastPathNow@netscape.net" at "Jun 26, 2001 01:47:59 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> Luigi,
> A slightly more concise way of making the same change would be as follows:
>
> #define TCPS_HAVERCVDFIN(s) ( (s) >= TCPS_CLOSE_WAIT || ((s) >= TCPS_CLOSING && (s) != TCPS_FIN_WAIT_2) )
the problem is that a graph (which is what ultimately
is a state diagram) does not generally have a total
ordering so making comparisons other than == or != is
the best way to induce programming errors.
> be possible to do interesting things things like state tracking
> for individal connections, such that every time we move into the
> next state instead of doing something like tp->t_state = TCPS_SYN_RCVD,
> we can have something like tp->t_state |= TCPS_SYN_RCVD . The only
> useful purpose that I can think of would be have a history of the
> past states in the t_state variable.
> Even without this ORing change, it would still make writing macros such as the above easier
No way! that would be even more wrong.
One state is one bit, and state changes are strict assignments.
The bit-set only makes it more efficient to test for set membership
( "state \in {S1, S2, S3 ...}" becomes ( tp->t_state & (S1|S2|S3) != 0 )
cheers
luigi
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106261837.UAA98582>