Re: [lwip-devel] [bug #44032] LWIP_NETCONN_FULLDUPLEX: select might work on invalid/reused socket

[Joel Cunningham]

Fabian,

I understand those use cases, the margin of error on using close to cancel blocking I/O on child threads is very small though.  If the child attempts to do anything with that stale socket, it could be potentially affecting any new socket instances.  The parent thread would have to use join() after issuing the closure to ensure no new sockets are created while the child thread cleanups and exits.  I would not recommend this model to any novice developer because it's so easy to get wrong.

My main concern is that LwIP's socket/FD model continue to match existing POSIX FD behaviors and we encourage developers to avoid the stale FD trap.  This way we can have applications with threading models that can be portable to different platforms

Joel

On Mar 17, 2015, at 03:27 AM, Fabian Koch <address@hidden> wrote:

Hey Joel,

Well the ultimate problem that "the application" has to keep track of all its sockets over all different threads involved will never go away, but I guess that's a given.

So you have scenarios like this:

"main application thread" creates a socket, creates a child thread, gives the socket fd to the child thread but keeps track of it too.
Now when the child is blocking on accept() and the whole application is supposed to be shut down, the main app thread can call close() on the socket that the child thread is waiting on without the universe exploding as it used to be in LWIP.

Same thing for full duplex protocols. They will also need a main thread that creates a send and a receive thread and gives them the fd of a socket to send/rec on. Or either of them creates a sockets and provides the others with the fd.
Still you should have one main thread that keeps track of all socket fds.

So in essence, implementing the long awaited "multiple threads can work on the same socket" feature in LWIP of course does not change the fact that application developers need to know what they are doing with their sockets.
Now they just have to spread that knowledge among more threads than one.

Cheers,
Fabian

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