Tk Source Code

View Ticket
Login
2014-03-13
09:18 Ticket [2507326fff] build problem with amsn and 8.6b1 status still Closed with 1 other change artifact: db3d6fbfcd user: jan.nijtmans
09:02 Ticket [2507326fff]: 1 change artifact: 7ed5fadaaa user: jan.nijtmans
2009-02-27
16:24 Ticket [2507326fff]: 4 changes artifact: 6175185243 user: teopetuk
15:44 Ticket [2507326fff]: 4 changes artifact: dac697ca3e user: nijtmans
04:06 Ticket [2507326fff]: 4 changes artifact: f0de208c0b user: teopetuk
2009-01-15
17:40 Closed ticket [2507326fff]. artifact: 0f1c5f2130 user: nijtmans
2009-01-14
16:27 New ticket [2507326fff]. artifact: c165e2b3de user: nijtmans

Ticket UUID: 2507326
Title: build problem with amsn and 8.6b1
Type: Bug Version: obsolete: 8.6b1
Submitter: jan.nijtmans Created on: 2009-01-14 16:27:37
Subsystem: 41. Photo Images Assigned To: jan.nijtmans
Priority: 5 Medium Severity:
Status: Closed Last Modified: 2014-03-13 09:18:23
Resolution: Fixed Closed By: nijtmans
    Closed on: 2009-01-15 10:40:57
Description:
This artifact is meant to fix the build problem in amsn,
as discussed in:
<http://aspn.activestate.com/ASPN/Mail/Message/tcl-core/3685995>

After studying the aMSN code, aMSN assumes that Tk makes
an internal copy of formatPtr->name, although Tk documents
that formatPtr->name must be available during the full
lifetime of the thread.

Making a copy, as Tk 8.5.5 and earlier did, adds only
4 lines of code to Tk, so it is much simpler to implement
than any other solution. Will do that.
User Comments: teopetuk added on 2009-02-27 16:24:43:
Do I understand correctly that the original change is in http://tktoolkit.cvs.sourceforge.net/viewvc/tktoolkit/tk/generic/tkImgPhoto.c?r1=1.76&r2=1.76.2.1 and the reverted change is in http://tktoolkit.cvs.sourceforge.net/viewvc/tktoolkit/tk/generic/tkImgPhoto.c?r1=1.76.2.1&r2=1.76.2.2 ?

It look slike the reversion wasn't complete. See the cumulative change: http://tktoolkit.cvs.sourceforge.net/viewvc/tktoolkit/tk/generic/tkImgPhoto.c?r1=1.76&r2=1.76.2.2

As for now functions Tk_CreatePhotoImageFormat() and Tk_CreateOldPhotoImageFormat() behave inconsistently: the former one copies format name and the latter one doesn't.

Wouldn't it be better to copy name in Tk_CreateOldPhotoImageFormat() also?

nijtmans added on 2009-02-27 15:44:39:
Change is already reverted, as it was in Tk 8.5.5, except for
the handling of multiple threads. As long as everything is in
a single thread (as usual with Tk) it will work as before.

The bug in aMSN is already fixed in the CVS version,
but this version is not released yet. The fact that
formatPtr->name must be long term available is
documented in the header files, not in the manpage.
So I cannot really blame aMSN for doing this. But
there might be more extensions doing the same,
therefore I decided to revert the copying. It
takes some memory, but is harmless, that's all.

teopetuk added on 2009-02-27 04:06:17:
I'd like to ask if this copying of format name breaks anything? If it breaks and it's documented that formatPtr->name must be available during the full lifetime of the thread then may be it's better to fix the bug in aMSN? But if copying name is harmless then it's better to reverse the change fully, otherwise Tk_CreatePhotoImageFormat() and Tk_CreateOldPhotoImageFormat() will behave differently.

By the way, where is it documented that formatPtr->name must be long term available? I can't find that in manpage.

nijtmans added on 2009-01-15 17:40:57:
Fixed, and backported for Tk 8.5.7. Further comments
are still accepted.