[En-Nut-Discussion] Suggested modification to nut\net\tcpsm.c again

[Nathan Moore]

On Thu, Nov 12, 2009 at 11:41 AM, Harald Kipp <harald.kipp at egnite.de> wrote:


>  > Best thing would be to use uint_fast16_t, I think.
>
> That will optimize 32-bit code. But it scares *me* to mix up fixes with
> optimizations. As explained to Zack, I don't see any other advantage.
>
> Let's do the fix first and then think about optimizations.


Yeah.  I just threw that in there because Zack asked why it was 16 bit.


> There is  plenty of room here in the TCP stack. In fact I discovered the
> problem
> while trying to do some performance tests.
>

It certainly would be nice if the stack were a little bit smarter, but it's
so complicated.

>
>
> > that someone will forget to |= 1 it.
>
> May a comment line help?


Maybe.  And I'm sure that if anyone sends you TCP patches the usage of this
variable
is probably one of the first things you look for so bad code getting into
official Nut isn't
that likely.


> Or is there a better solution which doesn't require additional RAM space?
>

I don't know.  I've been thinking about this particular code a lot, and I
think that the easiest
to understand thing would be to use one of the free bit in so_tx_flags for
the same purpose
as setting so_rtto to 0.

Nathan