Close message different behaviour on Mac and Linux.

i am implementing multi-threaded websocket client server chat application. On client side i am using rust-websocket library, while on the server side i am not using this library rather manually reading from the socket(TcpStream) connection.

On server side i am trying to read the data as let buf = socket.read_u16::<BigEndian>()?;
where read_u16 is from byteorder::io::ReadBytesExt.
it work fine for the text message sent by the client,
The issue starts when we try to close any client by sending close message to the server as below,

let close_msg = Message::close();
let res = sender.send_message(&close_msg);

while reading this message on server side, with let buf = socket.read_u16::<BigEndian>()?; , it is successful on mac, but while in Linux it fails with wouldblock error i.e:

thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" }

On other hand if we send as close message using ping,

let close_msg = Message::ping(vec![1u8]);;
let res = sender.send_message(&close_msg);

then it don't give the above error and is successful on linux .
I didn't understand why it behave different on mac and linux , can anyone please help?

Start with the server's TcpStream read_u16::() path and the client's Message::close() and Message::ping() calls. Reproduce both cases on Linux and macOS, then inspect the WebSocket close-frame handling and nonblocking read behavior. Done means the platform difference and WouldBlock result are explained and the issue has a verified resolution.