Re: [lwip-users] Multi-threaded socket access once again

[Joel Cunningham]

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 <address@hidden> 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
       > address@hidden
       > https://lists.nongnu.org/mailman/listinfo/lwip-users
       >
       >


_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users