linux下recvfrom阻塞状态下退出的问题和pthread_detach后的线程退出了以后线程资源的释放问题？

[kgduwu]

控制器上linux主线程main(不异常永远不会退出)创建了常驻线程inA(不异常永远不会退出)来接收来自socketA网络地址和端口的数据，
当上位机PC软件给控制器的socketA网络地址和端口发送数据：
1.如果socketA网络地址和端口的数据命令是启动socketB网络地址和端口的数据接收时，常驻线
程inA会创建线程inB,并且调用pthread_detach(inB)断开自己与inB的关系,而线程inB
以阻塞方式循环调用recvfrom来接收socketB网络地址和端口的数据。
2.如果socketA网络地址和端口的数据命令是关闭socketB网络地址和端口的数据接收时，常驻线程inA
会关闭socketB网络地址和端口，使socketB网络地址和端口的recvfrom从阻塞中跳出，并线程inB自己跳出循环，线程inB运行结束，自己释放自己占用的资源。

现在的问题是：
1.线程inA直接调用close（socketB）不能像windows一样使socketB网络地址和端口的recvfrom从阻塞中
跳出。
2.网上有人说可以调用shutdown（socketB，SHUT_RDWR）然后调用close（socketB）来使recvfrom从阻塞中跳出，这样调用了以后线程inB中的recvfrom的确是从阻塞中返回了，字节长度为0，然后是线程inB跳出了循环并退出。然后不能达到预期的是：
A：通过top命令查看程序的线程占用发现，系统并没有释放线程inB创建时占用的内存资源。
B：当上位机PC软件再次给socketA发送启动线程inB命令时，线程inB启动并进入到recvfrom阻塞中，但是PC软件给sockeB发送数据时，之前能正常接收的socketB总是返回0（recvfrom返回值是接收到的数据长度，为0），并且reboot软重启或硬复位控制（不断电），PC软件给socketB发出数据，recvfrom仍返回0，只有在控制器断电重启以后，socketB才能恢复。

[空的]

说的好复杂，直接上代码比较靠谱 进程 申请内存后释放不会真正释放，只是保留起来，进程下次再申请就用可能用到这个了，这属于内存管理啥的 后面那个应该是代码上的问题吧

[KeequenLiu]

把recvfrom 换成select非阻塞式，避免阻塞接收线程