I ran into a similar problem recently, and overcame it using 'nested interrupts'. I don't know if this would be the best method for you, but here it is..
Basically, every time an interrupt is triggered, global interrupts are disabled while it completes, so other interrupts cannot run.
The way I used around that, the main steps would be something like follows:
(I posted some info on my blog too: TMRh20s Project Blog: July 2012)
a: COMPB interrupt triggered
b: Disable COMPB interrupt from within the COMPB interrupt vector
c: Enable 'Global Interrupts'
d: Let COMPB do its thing, OVF will interrupt it when it needs to read Serial data
e: Last step before COMPB completes is to re-enable itself
It would require two interrupts the way I see it, but the code might be something like this:
ISR(TIMER1_COMPB_vect){
TIMSK1 &= ~_BV(OCIE1B); //Disable this interupt, otherwise seems like it will try to trigger again next cycle even if not complete
sei(); //Now enable global interupts before this interrupt is finished
// take as long as you like to do what you need here, this interrupt will keep trying to complete while other interrupts... interrupt it
// while(x < yourMom){delay{10)}
TIMSK1 = ( _BV(OCIE1B) | _BV(TOIE1) ); //Re-enable this interrupt
}
ISR(TIMER1_OVF_vect){
//check for serial data at a defined rate and have your way with it
}
Then you just have to work out the timing period and configuration on timer1 that works best with your code. You can also modify the duty cycle on your timer on the fly, which would affect the timing of COMPB and possibly OVF depending on configuration.
Edit to add: I just remembered this partial implementation of Serial.bufferUntil() I found a while back: Added methods buffer(size) and bufferUntil(char) to Serial, WIP · cmaglie/Arduino@86ae0f9 · GitHub and Google Code Archive - Long-term storage for Google Code Project Hosting. this may be closer to what you are looking for