[Tcl-bugs] [ tcl-Patches-727786 ] JANITORIAL: dead/DEPRECATED code in tclUnixChan.c

[SourceForge.net <no...@so...>]

Patches item #727786, was opened at 2003-04-25 15:17
Message generated for change (Comment added) made by andreas_kupries
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310894&aid=727786&group_id=10894

Category: 25. Channel System
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Joe English (jenglish)
Assigned to: Andreas Kupries (andreas_kupries)
Summary: JANITORIAL: dead/DEPRECATED code in tclUnixChan.c

Initial Comment:
The attached patch simply removes the code currently
#ifdef'ed out in tclUnixChan.c. (See followup for
explanation).

----------------------------------------------------------------------

>Comment By: Andreas Kupries (andreas_kupries)
Date: 2004-10-28 13:23

Message:
Logged In: YES 
user_id=75003

Uploading updated patch.

----------------------------------------------------------------------

Comment By: Joe English (jenglish)
Date: 2003-11-24 18:13

Message:
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.

----------------------------------------------------------------------

Comment By: Joe English (jenglish)
Date: 2003-04-25 15:20

Message:
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  <md...@us...>.

 * * *

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.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310894&aid=727786&group_id=10894