Gurusamy Sarathy <gsar@ActiveState.com> writes: >On Mon, 10 Apr 2000 08:26:14 BST, Nick Ing-Simmons wrote: >>Gurusamy Sarathy <gsar@ActiveState.com> writes: >>> >>>I'd say peek() should make a copy when moving it to the pad if the >>>SV is already a PADTMP. >> >>What does PADTMP _mean_ ? (And where does one look fror such definitions?) > >It simply signifies that the SV is lives on the scratchpad. Such SVs >are of two kinds. One kind has names (i.e. have corresponding entries >in the comppadname array) and are usually lexical/our variables. The >other kind are nameless "temporaries" that may be allocated by any OP >for use during its lifetime. So a "better" name would be "IN_A_PAD" ;-) > >>Is setting PADTMP on a constant the right thing to do in the first place? > >Yes. The constant SV is moved to the pad in order to keep it separate >between different threads that might share the same op tree. Presumably then this is one of the 'named' kind - as we don't want constants being used as scratch. So perhaps there are three types: 1. named variables 2. constants 3. Pad temporaries. >(Otherwise, >you'd have to lock access to the constant, which we don't want to do. >And besides, constants are subject sv_upgrade() etc., which will break >things when multiple threads share the same SV.) Ick. I thought you could not upgrade if SvREADONLY was on? I have certainly been bitten by that in the past. -- Nick Ing-Simmons <nik@tiuk.ti.com> Via, but not speaking for: Texas Instruments Ltd.Thread Previous | Thread Next