See Tie::Handle and the documentation that it references (mostly perltie).

Using that you can make a handle that hides the real file handle inside of itself. Then you can have your handle's implementation of READLINE squirrel away a copy of the read line to an internal buffer. You'd implement a SEEK that would set an attribute so that the next call to READLINE would read from the hidden buffer.

But mixing byte-offset logic (seek) with read-line logic gets to be a pain. So implementing such a tied handle such that it can take care of all of the general cases may be more work than reworking your code a tiny bit so that you are calling methods and then implementing an object that only supports the functionality you need (read next line, save this line and subsequent lines, go back to the saved line, etc.). That way you could deal only in "lines".

Alternately, you could implement a tied handle that works well enough if you only use it in the ways that your program currently does. So, for example, tell() would give you back a line number not a byte offset and trying to READ instead of READLINE would croak.

I'd skip all the seeks and tells and use a thread and a queue this way:

#! perl -slw
use strict;
use threads;
use Thread::Queue;

my $file = $ARGV[ 0 ];

my $Q = new Thread::Queue;
async {
    open LIBBIN, "gunzip -c $file |" or die $!;
    while( <LIBBIN> ) {
        $Q->enqueue( $_ );
        sleep 1 while $Q->pending > 100;                  ## Arbitrary
+ limit to stop it from running away with memory
    }
    $Q->enqueue( undef ); ## close queue
}->detach;

## Main code swaps $Q->dequeue for <LIBBIN> ...

while( my $line = $Q->dequeue ) {

   if( some circumstance ) {
       unshift @{ $Q->{queue} }, $line;                 ## 'push' a li
+ne back to the queue.
   }
   
   ## do other stuff here..
   
}
[download]

The only slightly 'trick' thing here is that I'm reaching inside the Queue object to gain access to the underlying array reference with $Q->{queue}, which the OO purists would have a hissy fit about, but to my mind one of the big advantages of Perl's simple native OO mechanism, is that I as a user can easily extend -- or in this case regain access to existing -- functionality without having to go cap in hand to the authors of the module or complicate things with OO complexity.

If the basic mechanism of having a separate thread doing the IO and a queue to buffer the data fits with your mindset, then you should also take a look at the "ADVANCED METHODS" in the Thread::Queue docs. For the most part I consider their addition to the queue module an abomination, but for the first time ever, I can see your application might find them useful.

I need to pre-fetch some keywords in each section to properly build a data structure. The position of the keywords can be anywhere within the section.

Why not read a whole section into a buffer, scan the the buffer for the keywords, then process the whole section.

Maybe read your file with IO::Uncompress::Gunzip? The synopsis says it supports tell() and seek().

OK, thought the suggestion of using the IO::Uncompress was great. BUT sad face ;( message returned below tells me that it is not an option to seek backwards with the module:<\p>

<\p>

IO::Uncompress::Gunzip::seek: cannot seek backwards at ...<\p>