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

控制器上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才能恢复。

|

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

|

说的好复杂，直接上代码比较靠谱

进程 申请内存后释放不会真正释放，只是保留起来，进程下次再申请就用可能用到这个了，这属于内存管理啥的

后面那个应该是代码上的问题吧