summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorferrieux <ferrieux@users.sourceforge.net>2013-01-13 18:12:41 (GMT)
committerferrieux <ferrieux@users.sourceforge.net>2013-01-13 18:12:41 (GMT)
commitbba96eb5807020d22f0456cfdec86e4364265944 (patch)
tree3869c28f983998e66fd202364be205c418e377a0
parentac11a249f5f3b0953155d8b03999874e772bad05 (diff)
downloadtcl-bba96eb5807020d22f0456cfdec86e4364265944.zip
tcl-bba96eb5807020d22f0456cfdec86e4364265944.tar.gz
tcl-bba96eb5807020d22f0456cfdec86e4364265944.tar.bz2
Clarify readable fileevent "false positives" in the case of multibyte encodings/transforms [Bug 3436609].
-rw-r--r--ChangeLog4
-rw-r--r--doc/fileevent.n17
2 files changed, 14 insertions, 7 deletions
diff --git a/ChangeLog b/ChangeLog
index 9cfa769..83e7053 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2013-01-13 Alexandre Ferrieux <ferrieux@users.sourceforge.net>
+ * doc/fileevent.n: Clarify readable fileevent "false positives" in
+ the case of multibyte encodings/transforms [Bug 3436609].
+
2013-01-13 Jan Nijtmans <nijtmans@users.sf.net>
* generic/tclIntDecls.h: If TCL_NO_DEPRECATED is defined, make
diff --git a/doc/fileevent.n b/doc/fileevent.n
index df48d2a..e453748 100644
--- a/doc/fileevent.n
+++ b/doc/fileevent.n
@@ -80,13 +80,16 @@ A channel is considered to be writable if at least one byte of data
can be written to the underlying file or device without blocking,
or if an error condition is present on the underlying file or device.
.PP
-Event-driven I/O works best for channels that have been
-placed into nonblocking mode with the \fBfconfigure\fR command.
-In blocking mode, a \fBputs\fR command may block if you give it
-more data than the underlying file or device can accept, and a
-\fBgets\fR or \fBread\fR command will block if you attempt to read
-more data than is ready; no events will be processed while the
-commands block.
+Event-driven I/O works best for channels that have been placed into
+nonblocking mode with the \fBfconfigure\fR command. In blocking mode,
+a \fBputs\fR command may block if you give it more data than the
+underlying file or device can accept, and a \fBgets\fR or \fBread\fR
+command will block if you attempt to read more data than is ready; a
+readable underlying file or device may not even guarantee that a
+blocking [read 1] will succeed (counter-examples being multi-byte
+encodings, compression or encryption transforms ). In all such cases,
+no events will be processed while the commands block.
+.PP
In nonblocking mode \fBputs\fR, \fBread\fR, and \fBgets\fR never block.
See the documentation for the individual commands for information
on how they handle blocking and nonblocking channels.