sys.net.Socket and timeouts

Let’s say I have this code:

    var server = new sys.net.Socket();
    server.bind( new sys.net.Host('127.0.0.1'), 4242 );
    server.listen(1);
    trace('listening on localhost:4242');
    var client = server.accept();
    client.setTimeout( 5.0 );
    trace('data',client.input.readByte());
    trace('data',client.input.readByte());
    client.close();
    server.close();

and I run it on eval target (--run or --interp), it will listen for connections on port 4242:

$ listening on localhost:4242

and if I send two bytes to localhost:4242, i.e. using netcat like so:

echo -n "AB" | nc localhost 4242

I’ll see

$ listening on localhost:4242
$ data,65
$ data,66
$

in the first terminal. Server received two bytes, printed them out and shutdown. Perfect.

My problem starts when I run the server and then send just ONE byte, i.e. with this:

echo -n "A" | nc localhost 4242

server says:

$ listening on localhost:4242
$ data,65

and then both server and client (nc) just hang there forever (or until I get bored and Ctrl+C both).

I would expect that client.input.readByte() would throw exception after 5 seconds because I setTimeout(5) on the client, but it does not.

Am I misunderstanding setTimeout documentation which says blocking reading and writing operations will abort after given time?
Or is setTimeout just for Socket.read and Socket.write methods and not the ones on Socket.input?

Also, if I start above server code in one terminal, and send ONE byte in another as described above, and then terminate netcat (i.e. that means client has closed the connection), I would expect for second readByte to throw EOF exception (or any exception) but instead I see this:

$ listening on localhost:4242
$ data,65
$ data,0
$

in other words, the second readByte hasn’t thrown exception but it returned 0. I’m super confused.

I’ve spent entire afternoon today trying to figure out how to use timeout to stop waiting for data on socket without resorting to handcrafting a custom solution with Timers and what not, so any insights into a “proper” hadnling of Socket timeouts would be appreciated.

To follow up on this: the issue only seems to happen on eval target, neko and hl work as expected.