Starting with Tcl 7.6, calling Tcl_MakeFileChannel() with the
same inFd and outFd as a previously allocated FileChannel would
return the old FileChannel instead of allocating a new one.
It's not clear why this was done -- this behaviour was not
documented -- but possibly related to the following changelog
entry:
5/23/96 (bug fix) Fixed bug that allowed
Tcl_MakeFileChannel to create new
channels with Tcl_Files in them that are already used by
another channel.
This would cause core dumps when the Tcl_Files were
being freed twice. (JL)
At some point between 7.6 and 8.0, the Tcl_MakeFileChannel() API
was reworked:
4/23/97 (removed feature) The Tcl_File interfaces have
been removed.
The Tcl_CreateFileHandler/Tcl_DeleteFileHandler
interfaces now take
Unix fd's and are only supported on the Unix platform.
Tcl_GetChannelFile has been replaced with
Tcl_GetChannelHandle.
Tcl_MakeFileChannel now takes a platform specific file
handle. (SS)
*** POTENTIAL INCOMPATIBILITY ***
Tcl 8.0 also kept track of a global list of open file channels,
and returned an existing channel if a call to
Tcl_MakeFileChannel()
specified a previously used file descriptor. This behaviour was
not documented in 8.0 either. The list of open file
channels was not
used for any other purpose.
In Tcl 8.1, the global list of file channels was replaced with
a thread-specific list (CVS revision 1.10, r1.1.2.1). The
caching
behaviour was still not documented.
Shortly after Tcl 8.3.2, the per-thread list of file descriptors
was (temporarily) #ifdef'ed out, since it caused problems with
transferring channels. From the CVS log:
* unix/tclUnixChan.c: #ifdef'd the thread-local list of file
channels as it prevents us from transfering channels.
To restore
this we may need an extended interface to drivers in the
future. Target: 9.0. Found while testing the new
transfer of
channels. The information in this list for a channel
was left
behind and then crashed the system during finalization.
The code has remained #ifdef'ed out since then, although
a patch has since been applied to make it work properly
if -DDEPRECATED is supplied; see ChangeLog entry
2003-01-25 Mo DeJong <mdejong@users.sourceforge.net>.
* * *
SUMMARY: since this part of the code (a) is only used to
implement an undocumented and quite-possibly incorrect feature,
and (b) has been disabled throughout the 8.4 series without
any noticeable ill effect, I believe it can be safely removed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=68433
History:
Starting with Tcl 7.6, calling Tcl_MakeFileChannel() with the
same inFd and outFd as a previously allocated FileChannel would
return the old FileChannel instead of allocating a new one.
It's not clear why this was done -- this behaviour was not
documented -- but possibly related to the following changelog
entry:
5/23/96 (bug fix) Fixed bug that allowed
Tcl_MakeFileChannel to create new
channels with Tcl_Files in them that are already used by
another channel.
This would cause core dumps when the Tcl_Files were
being freed twice. (JL)
At some point between 7.6 and 8.0, the Tcl_MakeFileChannel() API
was reworked:
4/23/97 (removed feature) The Tcl_File interfaces have
been removed.
The Tcl_CreateFileHandler/Tcl_DeleteFileHandler
interfaces now take
Unix fd's and are only supported on the Unix platform.
Tcl_GetChannelFile has been replaced with
Tcl_GetChannelHandle.
Tcl_MakeFileChannel now takes a platform specific file
handle. (SS)
*** POTENTIAL INCOMPATIBILITY ***
Tcl 8.0 also kept track of a global list of open file channels,
and returned an existing channel if a call to
Tcl_MakeFileChannel()
specified a previously used file descriptor. This behaviour was
not documented in 8.0 either. The list of open file
channels was not
used for any other purpose.
In Tcl 8.1, the global list of file channels was replaced with
a thread-specific list (CVS revision 1.10, r1.1.2.1). The
caching
behaviour was still not documented.
Shortly after Tcl 8.3.2, the per-thread list of file descriptors
was (temporarily) #ifdef'ed out, since it caused problems with
transferring channels. From the CVS log:
revision 1.18
date: 2000/05/02 22:02:37; author: kupries; state:
Exp; lines: +24 -4
* unix/tclUnixChan.c: #ifdef'd the thread-local list of file
channels as it prevents us from transfering channels.
To restore
this we may need an extended interface to drivers in the
future. Target: 9.0. Found while testing the new
transfer of
channels. The information in this list for a channel
was left
behind and then crashed the system during finalization.
The code has remained #ifdef'ed out since then, although
a patch has since been applied to make it work properly
if -DDEPRECATED is supplied; see ChangeLog entry
2003-01-25 Mo DeJong <mdejong@users.sourceforge.net>.
* * *
SUMMARY: since this part of the code (a) is only used to
implement an undocumented and quite-possibly incorrect feature,
and (b) has been disabled throughout the 8.4 series without
any noticeable ill effect, I believe it can be safely removed.
Patch to tclUnixChan.c r1.44
Logged In: YES
user_id=68433
Old patch has gone stale; uploading new one.
Is there any reason to keep this code around? It's unused,
and it's very likely incorrect.
Logged In: YES
user_id=75003
Uploading updated patch.
Unified diff. Removal of DEPRECATED, v3.
Logged In: YES
user_id=75003
Committed to head. Added mail discussion between Joe, Jacob,
and myself.
Mail discussion