On 18/04/2012 6:07 AM, Trevor Davel (Twylite) wrote:
> On 2012/04/18 02:28 AM, Jeff Hobbs wrote:
>> These kinds of things are best not changed back arbitrarily without
>> allowing for some internal switch to flip it back. I would strongly
>> advocate for a ::tcl::unsupported::flushOnExit variable that could allow
>> any user that relied on this behavior to maintain it.
> On 2012/04/18 02:38 PM, Andreas Leitgeb wrote:
>> In my opinion, discarding stuff shouldn't be the "default-behaviour".
>> While I understand the need for *some* change, to allow processes to
>> discard-and-close channels, it's the discarding case that should need
>> some extra code, not the "wait-till-all-is-written-out"-case.
> fconfigure $ch -flushOnExit 0 ;# defaults to 1
> Maintains backwards compatibility, allows code modules to implement the
> intended behaviour irrespective of global configuration.
Alexandre Ferrieux wrote:
> OK, the compat flag is a good idea. But what about an env var (as in
> Larry's example) rather than a script-level var ?
> The idea is that with an env var, you can force compatibility over
> *untouched* (even wrapped, tbc'ed, etc) code.
There is certainly a hierarchy of control points for switchable
behavior. If you look at the PCRE-enabled regexp patch I made, you
could control the default engine at
- compile time
- environment var
- interp level
- per regexp call
where each successive control point overrides the last. IIRC, even the
C side had a flag and switching behavior was recognized in regexp
Anyway, let's consider the use cases for the flushOnExit behavior, and
whether it warrants that level of detail (which isn't much work for the
Unlike regexps, which are used all the time, we are dealing with program
exit behavior only. Alex asked about the env var option, for the
system-exterior value. If the code is wrapped, then it would require
rewrapping with the newer core before behavior could change. In
addition, the wrapping case is meant for easy deployment - you generally
cannot rely on the system env, and should not. Thus, the internal var
is really the best solution there. I understand Larry's use in a fully
baked program, but we are talking detail at the language level. In
general, I wouldn't want to rely on env vars as any primary source for
influencing core language behavior. Having them in addition is a
nicety. As this is exit behavior, we shouldn't worry about the speed
cost of getenv, but we should make sure it's fully safe to use in teardown.
I wouldn't advocate compile time control for flushOnExit behavior, so
users could always know Tcl has default behavior of "X" (but I may be
swayed on this one). I do like the idea of a fconfigure -flushonexit
option, as this is very apt for the kind of selective need for some
channels to need this behavior, but I think the
::tcl::unsupported::flushOnExit control (which would be per interp
Tcl_LinkVar) is still necessary to cover many bases. You could even
make it 'interp default -flushonexit ?<bool>?' (introducing a new
subcommand would open up formalizing lots of sometimes hidden