Update of /cvsroot/tcl/tcl
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv19830
Modified Files:
ChangeLog
Log Message:
Add more examples to documentation along the lines of David Welton's project.

Feature Requests item #936546, was opened at 2004-04-16 15:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=360894&aid=936546&group_id=10894
Category: 70. Sample Extension
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Don Porter (dgp)
Assigned to: Nobody/Anonymous (nobody)
Summary: TEA: min Tcl version check
Initial Comment:
One thing an extension may want to
check during configuration is whether
the tclConfig.sh file found is for a
recent enough Tcl release to cover
the extension's build requirements.
It's simple to add checks against
TCL_MAJOR_VERSION and
TCL_MINOR_VERSION directly
in the configure.in file, but it might
be nicer if the TEA_ macros did
this for all extensions consistently.
Perhaps an argument to
TEA_LOAD_TCLCONFIG to
indicate the version requirement
of the extension?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=360894&aid=936546&group_id=10894

Bugs item #932314, was opened at 2004-04-09 10:11
Message generated for change (Comment added) made by dgp
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=932314&group_id=10894
Category: 36. File System
Group: development: 8.5a2
Status: Open
Resolution: None
Priority: 5
Submitted By: Don Porter (dgp)
Assigned to: Zoran Vasiljevic (vasiljevic)
Summary: epoch safety in threads?
Initial Comment:
The interal rep of a "path" Tcl_Obj
can remember things, like which
filesystem has claimed it. Each
"path" Tcl_Obj remembers a
filesystemEpoch value, to help
determine whether the cached
information still agrees with the
authoritative data structures.
The epoch value checking done
within tclPathObj.c always compares
the filesystemEpoch value in the "path"
to the tsdPtr->filesystemEpoch value,
which characterizes the local thread's
copy of the master filesystem data structures.
That will keep the "path" values consistent
with the thread's view of the filesystem
state, I agree.
However, the Tcl_FSRegister(),
Tcl_FSUnregister(), and Tcl_FSMountsChanged()
routines all directly manipulate the
master per-process filesystem data.
The per-thread cache of that data will
be out of date until some routine in
the thread calls FsGetFirstFilesystem()
in tclIOUtil.c.
It appears to me then, that the epoch
checking of "path" values isn't really
checking validity unless somehow
threads are prompted to call
FsGetFirstFilesystem() when the
master data changes.
As one example, consider
Tcl_FSGetFilesystemForPath().
It calls TclFSEnsureEpochOk()
which will check that the epoch
within the "path" is the same as
that of the thread's copy of the
filesystem. If so, then the cached
filesystem that claimed this "path"
before is returned.
Only later in Tcl_FSGFFP() is
FsGetFirstFilesystem() called,
so that it might be noticed that the
filesystem return is invalid (perhaps
now unregistered! or perhaps just
mounting changes have changed
the filesystem that has a valid claim)
That particular example can probably
be fixed by moving the FsGetFirstFilesystem()
call before the TclFSEnsureEpochOk() call,
but I'm also curious about the general issue
of keeping per-thread caches in sync with
the master data.
----------------------------------------------------------------------
>Comment By: Don Porter (dgp)
Date: 2004-04-16 11:12
Message:
Logged In: YES
user_id=80530
The routine Tcl_FSGetInternalRep(path, fs)
helps work around the worst of these issues.
I was mostly worried that a path value would
get passed in to a filesystem that claimed
it earlier, but no longer should.
In order to access the internal rep of that
path, though, the filesyste, has to make
that call, and an epoch check could, and
IMHO should, go in there. In fact any routine
that returns information from a cached
internal rep of a Tcl_Obj ought to verify
that the cache is still valid.
Tcl_ConvertToPathType() takes care
of the check against the thread-level
filesystem epoch. All that's missing
is a check that the thread-level value
is up to date with the process-level value.
----------------------------------------------------------------------
Comment By: Vince Darley (vincentdarley)
Date: 2004-04-13 06:56
Message:
Logged In: YES
user_id=32170
Assigning to Zoran who's responsible for (and understands
more clearly) the thread-safety side of things.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=932314&group_id=10894

Update of /cvsroot/tcl/tcl/doc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24307/doc
Modified Files:
socket.n
Log Message:
Added example from [Patch 936245] from David Welton.
Also some other minor bits of doc cleanup.

Update of /cvsroot/tcl/tcl
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24307
Modified Files:
ChangeLog
Log Message:
Added example from [Patch 936245] from David Welton.
Also some other minor bits of doc cleanup.

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details