use of static variables in tcp_in.c

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

use of static variables in tcp_in.c

Siva Velusamy
Hi,

tcp_in.c in lwIP 1.2.0 makes use of static global variables to pass arguments between functions. This implies that tcp_input is not re-entrant. However this doesn't seem to be documented in ethernetif.c or anywhere else. Is there something I'm missing here?

Thanks,
Siva
--
In the end, everything is a gag.
           Charlie Chaplin
_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE: use of static variables in tcp_in.c

Goldschmidt Simon
 
> tcp_in.c in lwIP 1.2.0 makes use of static global variables to pass
> arguments between functions. This implies that tcp_input is not
re-entrant.
> However this doesn't seem to be documented in ethernetif.c or anywhere
else.
> Is there something I'm missing here?

Does it have to be documented in ethernetif.c? Why would you call
tcp_input
more than once? That would mean you would call tcp_input (or maybe
netif->input)
from your netif->output function (which may be called in tcp_input).
That is
not allowed in RAW mode (API mode puts that packet on a queue only, so
the function
is not really called again). This is documented, for example in
loopif.c. Maybe
it should be documented better...

Simon


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE: use of static variables in tcp_in.c

Kieran Mansley
On Thu, 2007-10-04 at 09:21 +0200, Goldschmidt Simon wrote:

>  > tcp_in.c in lwIP 1.2.0 makes use of static global variables to pass
> > arguments between functions. This implies that tcp_input is not
> re-entrant.
> > However this doesn't seem to be documented in ethernetif.c or anywhere
> else.
> > Is there something I'm missing here?
>
> Does it have to be documented in ethernetif.c? Why would you call
> tcp_input
> more than once? That would mean you would call tcp_input (or maybe
> netif->input)
> from your netif->output function (which may be called in tcp_input).
> That is
> not allowed in RAW mode (API mode puts that packet on a queue only, so
> the function
> is not really called again). This is documented, for example in
> loopif.c. Maybe
> it should be documented better...

That said, is there any compelling reason to use static global variables
rather than function arguments?

Kieran



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE: use of static variables in tcp_in.c

Goldschmidt Simon

> >  > tcp_in.c in lwIP 1.2.0 makes use of static global
> variables to pass
> > > arguments between functions. This implies that tcp_input is not
> > re-entrant.
> > > However this doesn't seem to be documented in ethernetif.c or
> > > anywhere
> > else.
> > > Is there something I'm missing here?
> >
> > Does it have to be documented in ethernetif.c? Why would you call
> > tcp_input more than once? That would mean you would call
> tcp_input (or
> > maybe
> > netif->input)
> > from your netif->output function (which may be called in tcp_input).
> > That is
> > not allowed in RAW mode (API mode puts that packet on a
> queue only, so
> > the function is not really called again). This is documented, for
> > example in loopif.c. Maybe it should be documented better...
>
> That said, is there any compelling reason to use static
> global variables rather than function arguments?
>

Hehe, I remember complaining about that over a year ago. At that time,
I think the response was 'leave it as it is'...

Removing any global variables is also a necessary step when giving
the stack more multithreading capabilities (e.g. configuring high-
and low-prio connections to run in different threads...).

I think it would be a good thing moving from global variables to
parameters,
but I remember adam writing about intentionally using global variables
as a design goal in embedded systems (using a smaller stack, favouring
statically configured memory) which is an opinion I don't share, but we
would
have to discuss that!

Simon


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: use of static variables in tcp_in.c

Siva Velusamy
In reply to this post by Goldschmidt Simon


On 10/4/07, Goldschmidt Simon <[hidden email]> wrote:

> tcp_in.c in lwIP 1.2.0 makes use of static global variables to pass
> arguments between functions. This implies that tcp_input is not
re-entrant.
> However this doesn't seem to be documented in ethernetif.c or anywhere
else.
> Is there something I'm missing here?

Does it have to be documented in ethernetif.c? Why would you call
tcp_input
more than once? That would mean you would call tcp_input (or maybe
netif->input)
from your netif->output function (which may be called in tcp_input).
That is
not allowed in RAW mode (API mode puts that packet on a queue only, so
the function
is not really called again). This is documented, for example in
loopif.c. Maybe
it should be documented better...


Thanks, that is correct. I've only seen tcp_output being called, for instance, from a timer context (tcp_tmr) and from tcp context. Thanks for the clarification.

-Siva

_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: use of static variables in tcp_in.c

Jonathan Larmour
In reply to this post by Goldschmidt Simon
Goldschmidt Simon wrote:
>
> I think it would be a good thing moving from global variables to
> parameters,
> but I remember adam writing about intentionally using global variables
> as a design goal in embedded systems (using a smaller stack, favouring
> statically configured memory) which is an opinion I don't share, but we
> would
> have to discuss that!

I think Adam made a good design choice. The stack is designed to be
single-threaded so what's the point doing otherwise. I would add, though,
that it's not just a question of stack space (although that's a good enough
reason on its own), but also code space and performance - marshalling all
the various arguments into the right position for function calls would take
extra code and time. It would also add to register pressure.

Incidentally there are other ways to deal with different priority of
operations depending on the thread priority of the threads using the stack.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
  >>>> Visit us on stand 810 at The Embedded Systems Show 2007, NEC <<<<
  >>>> Oct 17-18 Birmingham, UK http://www.edaexhibitions.com/ess/  <<<<
------["The best things in life aren't things."]------      Opinions==mine


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: use of static variables in tcp_in.c

goldsimon@gmx.de

>>
>> I think it would be a good thing moving from global variables to
>> parameters,
>> but I remember adam writing about intentionally using global variables
>> as a design goal in embedded systems (using a smaller stack, favouring
>> statically configured memory) which is an opinion I don't share, but we
>> would
>> have to discuss that!
>
> I think Adam made a good design choice. The stack is designed to be
> single-threaded so what's the point doing otherwise. I would add,
> though, that it's not just a question of stack space (although that's
> a good enough reason on its own), but also code space and performance
> - marshalling all the various arguments into the right position for
> function calls would take extra code and time. It would also add to
> register pressure.
>
> Incidentally there are other ways to deal with different priority of
> operations depending on the thread priority of the threads using the
> stack.

What you say is true, of course when using the stack single-threaded.
But when it comes to multithreading, there are some restrictions with
this design choice. In the spirit of 'lw', however, I think we'll stay
with the current implementation...

Simon


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users