pd <
[email protected]> wrote:
But for my understanding a channel is always writable since you can
always write to it, thinking in a file you can always add a line or
byte, the same for a socket.
It is not correct to think a file can always be written into. Consider
a pipe between two processes (which is implemented as stdout of the
writer being the same file as stdin of the reader process).
A typical pipe buffer size is 4kib (4096 bytes).
If the reader consumes bytes at the rate of 1 byte per second, but the
writer writes bytes at the rate of 2 bytes per second, eventually the
4kib buffer will fill.
Once it is filled, the writer will only be able to write at the rate of
1 byte per second (same as the read rate of the reader).
What will happen at the "file interface" level for the writer is that 2
bytes before the buffer fills, a two byte write will complete
immediately. But once the buffer is full, a two byte write by the
writer will take two seconds to complete, and the writer will block in
the write() call for two seconds while the reader consumes two bytes.
Sure the key is without blocking but if you configure the channel to nonblocking then you always write to it without blocking.
Tcl's 'nonblocking' is an abstraction [1] where Tcl hides the underlying
stdio interface from you and allows you to pretend to write as much as
you like. Reality is the Tcl runtime is buffering your writes up in
memory for you beind the scenes.
One example I've found using 'writable' is [2] and I think the use
there is to detect when a socket is ready to send bytes to it, for
example when it's fully opened
Sockets can also block for the same reason as the pipe, the reader is
on a network that transmits 100 bytes per second, while the writer is
on a network that transmits 1000 bytes per second. If the writer
writes bytes at full speed, eventually it has to block to not overrun
the writer.
Note also, that even a disk file can block. If the disk is connected
via an interface capable of writing 1Mbyte/s, but the attached computer
CPU can write to the interface at 10Mbyte/s, eventually the CPU has to
be "blocked" from writing more data because the reader (the disk) can
not keep up.
[1] The C stdio interface provides "non-blocking" I/O by returning a
"status message" from the write() call that indicates: "blocked, try again later" and it is up to the programmer to write the appropriate retry
loop. Tcl hides that 'retry' complexity inside the runtime and exposes
its "files can always be written" abstraction to the script level.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)