buglwIP - A Lightweight TCP/IP stack - Bugs: bug #19816, Stop the tcpip_thread

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #19816: Stop the tcpip_thread

Submitter:  Frédéric Bernon <fbernon>
Submitted:  Mon 07 May 2007 11:15:26 AM UTC
   
 
Category:  None Severity:  1 - Wish
Item Group:  Feature Request Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Planned Release:  None
lwIP version:  None

Jump to the original submission

Mon 21 May 2007 04:44:04 PM UTC, comment #6: 

Finally, in my environment, "down" the stack is the same than "down" the network interfaces. So, I can call netifapi to remove them: no change is necessary.

About the memory leaks, NXP tools are not really great for that, so, I close this item (if someone else think it can be really useful, we could reopen later...).

Thank you Jonathan & Simon for your comments...

Frédéric Bernon <fbernon>
Group Member
Fri 11 May 2007 09:13:12 AM UTC, comment #5: 

Ah, OK, I thought you needed to somehow get a clean restart of the stack. That's because I suggested to simply reboot the target... Of course this is of no use if you want to check memory leaks ;-)

Simon Goldschmidt <goldsimon>
Group administrator
Fri 11 May 2007 09:09:43 AM UTC, comment #4: 

Ok with you about saying we can't stop the stack if any sockets/pcb are still open.

>Out of interest: why don't you simply reboot the target? That's what we do..


Why I need that? Just because to get a clean component in NXP environement, I should provide a function to "down" the stack (but I think the idea is more to "down" a network interfaces). Another aim is to check any memory leak in the whole system, and our "mem check" tools need to compare two "same" states (by example, at the beginning and the end of the main() function).

Note the severity is "1-Wish" for the moment...

Frédéric Bernon <fbernon>
Group Member
Tue 08 May 2007 06:40:38 AM UTC, comment #3: 

At least, you would have to implement a *_shutdown() function for each module that has an *_init() function now. That would be the standard way (resembeling object orientation:) ). I don't think it's that hard if you first shut down socket/netconn threads and make sure their resources are freed. But it would require some much more clean coding and of course much additional code...

Out of interest: why don't you simply reboot the target? That's what we do...

Simon Goldschmidt <goldsimon>
Group administrator
Mon 07 May 2007 07:16:54 PM UTC, comment #2: 

Here be dragons. To stop the stack properly you need to be able to free all its resources - all PCBs, packet queues, buffers in use, etc.

Handling TCP sockets in a *_WAIT state is tricky too.

Doing this cleanly would be hard, doing this without increasing the footprint for the majority who don't need it would be very challenging indeed! I think at a minimum, and to reduce the number of race conditions to prevent, it's best to say that you can't stop the stack if any sockets/PCBs are still open.

Jonathan Larmour <jifl>
Group Member
Mon 07 May 2007 11:30:59 AM UTC, comment #1: 

Hehe, when beginning to work with lwIP ports, I asked myself why there is no such thing like sys_thread_delete()...

The answer is that most embedded systems don't need to gracefully shutdown, but if you need it, why not implement it...

All you would need is a new message the tells tcpip_thread to exit the loop. But care has to be taken with the ports. I don't think that every port is tested to cope with thread functions returning...
In my port, there is an ASSERT if a thread function returns. This would have to be changed to delete the thread when its function returns.

Also, you have to make sure you stop all socket/netconn threads first so they don't sleep forever waiting for an answer from tcpip_thread.

Next, network drivers might need a stop() function?

Simon Goldschmidt <goldsimon>
Group administrator
Mon 07 May 2007 11:15:26 AM UTC, original submission:  

I would like to add a feature to enable to stop the tcpip_thread (to "down" the ip stack). Do you have some ideas or preferences?

Frédéric Bernon <fbernon>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jifl (Posted a comment)
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by fbernon (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-05-21 fbernon Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code