select returns right filehandle again, and.. read returns EOF. So whole the time select was triggered by eof event (EOF is "can_read" too).

In other words. IT WORKS!

last select is not finished. means process stuck on it.

You added a sleep to the client. Ergo: you created the exact scenario I warned you about in "And if your messages are not some exact multiple of 4K, the last line of every 4k block will be a partial message, and your wrapper will therefore block until the next 4k block has been filled and passed through, before that message will be completed.".

The problem here is that you've latched onto something completely irrelevant, to distract from the fact that your OP code makes no sense.

I was never suggesting that you should use <readline> & print; only that your code was exactly as vulnerable to the same issue -- an incomplete message, perpetual block -- as they are.

Ie. If you added that sleep in the same place in the client code, and ran it against your OP sysread() wrapper, it blocks in exactly the same way!

Your OP wrappers are useless, because they are vulnerable in exactly the same way as readline.

And that's the point.