[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [FWP] Benchmarking $|++



And people say local() isn't good for anything anymore...

sub bar {
	local $| = 1;
	quux(42);
	# more stuff which works in the unbuff.
}

sub quux {
	my $fourty_two = shift;
	local $| = 1;
	# enquux it
}

By using local() to dynamically scope a copy of $| you provide
buffering with a good nesting instinct.  However, you don't protect
yourself from rougue routines you call mucking with your copy of $|
(for instance, if quux() did C<$| = 1> instead of C<local $| = 1>
you'd be screwed.

Solution?  Fuck if I know.  You -could- pull a trick like make $| a
tied variable which only allows itself to be set at tying and screams
if its ever attempted to be set otherwise...


package Local::Buffer;

sub TIESCALAR {
	my $buff = $_[1];
	bless \$buff;
}

sub FETCH { return $$_[0] }

sub STORE {
	require Carp;  
	&Carp::carp("Attempt to store to global $| found!");
}


use constant DEBUG => 1;
sub bar {
	local $| = 1;
	tie $|, 'Local::Buffer', 1 if DEBUG;
	evil(...);
	# more stuff;
}

sub evil {
	$| = -1;
}

Thus evil() would (in theory) trip Local::Buffer's warning.

I think tchrist has a module to do something very similar with $_.

IMHO, to be safe localize your magic globals if you're going to set them.


On Tue, Nov 09, 1999 at 09:58:00AM +0200, Ariel Scolnicov wrote:
> Except that it nests properly.  Think of a routine which wants to
> unbuffer at the beginning & buffer it at the end.  Here's one way to
> do it:
> 
> sub bar {
>   $| = 1;
>   # do stuff
>   quux(42);
>   # More stuff which depends on unbufferedness
>   $| = 0;
> }
> 
> Simple, elegant, readable code (not to mention 8usec faster).
> 
> Now suppose the author of quux decided to do the exact same thing -
> start unbuffered output at the beginning of quux, end it before the
> return:
> 
> sub quux {
>   my $forty_two = shift;
>   $| = 1;
>   # quuxify $forty_two
>   $| = 0;
> }
> 
> Oops.  After the return from quux, $| == 0.
> 
> The problem is that "$| = 1" and "$| = 0" don't nest properly in
> pairs.  But "$|++" and "--$|" do nest -- so your code does what you
> think it does.
> 
> True, it doesn't work if somebody says "$|=11".  But at least it
> works, if used consistently (although 8usec slower, for each level of
> nesting).
> 
> PS. I wonder if we should also benchmark "$|=0" vs. "--$|"...
> 
> -- 
> Ariel Scolnicov        |"GCAAGAATTGAACTGTAG"            |ariels@compugen.co.il
> Compugen Ltd.          |Tel: +972-2-6795059 (Jerusalem)	\  100% recycled bits!
> 72 Pinhas Rosen St.    |Tel: +972-3-7658520 (Main office)`--------------------
> Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555  http://3w.compugen.co.il/~ariels
> 
> ==== Want to unsubscribe from Fun With Perl?  Well, if you insist...
> ==== Send email to <fwp-request@technofile.org> with message _body_
> ====   unsubscribe
> 

-- 

Michael G Schwern                                           schwern@pobox.com
                    http://www.pobox.com/~schwern
     /(?:(?:(1)[.-]?)?\(?(\d{3})\)?[.-]?)?(\d{3})[.-]?(\d{4})(x\d+)?/i

==== Want to unsubscribe from Fun With Perl?  Well, if you insist...
==== Send email to <fwp-request@technofile.org> with message _body_
====   unsubscribe