Hey Joel, well that's not LwIP specific. The usual BSD socket API works in the same way. If you want to design your application in that way, you need some application-wide resource management that can take care of that.
Kind regards, Fabian From: [email protected] [mailto:[email protected]] On Behalf Of Joel Cunningham Sent: Freitag, 18. Juli 2014 19:21 To: Mailing list for lwIP users Subject: Re: [lwip-users] Multi-threaded socket access once again Another problem beside the lwIP API not being designed for multiple thread access on the same socket, is an inability to detect stale socket (file) handles. Say you have an application 1 with two thread A for sending, B for receiving. Both threads share a socket allocated as "1" and hold references to that socket. During the execution of thread B, it closes socket 1. Thread A still has a reference to socket 1. If an application 2, thread C executes next (before thread A) and opens a socket, the lwIP stack may reuse socket 1 because it is now free and hands out a reference to application 2. Now when thread A gets around to running, any operations that it performs will be using application 2's socket Joel On Jul 18, 2014, at 10:12 AM, Steffen Wolfer <[email protected]<mailto:[email protected]>> wrote: Hi Fabian, thanks for your reply. The submitting threads should always be stopped before the application closes the socket. The receiver thread does all the socket management, like open, close, bind, accept etc. and also controls the other submitting threads. But I'm not sure what happens if the remote site closes the connection unexpectedly, so I'll have to check that. Regards, Steffen Am 18.07.2014 14:55, schrieb Fabian Koch: > Hey Steffen, > > <insert the usual "not supported answer" here first > > > Having said that, it seems like an okay setup if there are no other unexpected accesses. > For example if another task closes the socket while your receive task is in the select() you'll also be in trouble. > For our adaptation we modified LwIP to silently exit the select() call if that happens but in the official release, is runs into assertions. > > The whole ordeal of "access sockets from multiple tasks" is a big topic in my opinion and not something that LwIP can hide from. > I know the construct of the single op_completed semaphore and the mboxes is one of the main problems behind not being able to support multiple tasks, but the argument of no longer being light-weight is not true if we make all the necessary changes optional and flexible. > > Cheers, > Fabian > > _______________________________________________ > lwip-users mailing list > [email protected]<mailto:[email protected]> > https://lists.nongnu.org/mailman/listinfo/lwip-users > > _______________________________________________ lwip-users mailing list [email protected]<mailto:[email protected]> https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
