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: lwip-users-bounces+address@hidden [mailto:lwip-users-bounces+address@hidden
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
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
|