Closed yarreg closed 11 months ago
Hard to test this, when you get the chance, can you checkout master?
There's a new write_timeout_ms
which should error.Timeout
on a timeout. For handshake, the timeout_ms
that already existed for reads is being re-used. Hence, for handshake timeout_ms
now represents the read+write timeout.
@yarreg I'm considering an alternative approach, which is to replace os.poll with os.setsockopt for better compatibility with Windows.
There's a branch, nopoll with the changes.
Essentially, it would be up to the application to call client.stream.writeTimeout(MILLISECONDS)
and client.stream.writeTimeout(0)
to remove any previous set timeout.
Do you think that would work for you? I'd really like to have a single codepath that works for all platforms.
Sorry for delay. Yes it is suitable for me.
I've been working with the
Stream
structure and noticed that there's currently a poll method for reading operations only. While this works for most cases, in some specific network situations, I need to check if a socket is ready for a write operation. This is especially crucial when dealing with scenarios where write buffers might be full, or when there's a need to ensure non-blocking writes.read_timeout
andwrite_timeout
options. These would allow users to define timeout durations for reading from and writing to websockets, like this inClient.handshake