Design consideration: LPM pitfall possible?

Hi,

First of all, hi! Second, that I'm new to embedded programming and it seems I have to learn the basics. What's the problem: I'm doing a couple of different sensor measurement in my code. I have 2 sensors Timer-based (pseudo 1-wire protocol that I need to parse by verifying logic level intervals) and 1 I2C-based (BMP085).

init();
get_temp_data();
get_humidity1_data();
get_humidity2_data();

Now, while the Timer-based readings (humidity1 and humidity2) are sequential (each with while() loop finished when a complete set of reading is done), that means humidity2 cannot start before humidity1 is completed, the temp and humidity1 can be run concurrently - temp is I2C-interrupt-triggered, humidity is Timer-interrupt-triggered. Of course, I could make humidity1 start after temp completes, but I guess this is not good fashion

Now as for the LPM. Suppose the init() sets the appropriate interrupt setup and when did it calls the LPMx.  The I2C ISR is triggered and thus the get_temp_data() is served. But inside, the get_temp_data() has 

_bis_SR_register(CPUOFF + GIE)

 to enter LPM because we are waiting for further interrupts.

What will happen if the I2C and Timer interrupts are caught at the same time? They are prioritized, but in fact queued. Let's say the I2C will go first, enter the get_temp_data() and hit the 

_bis_SR_register(CPUOFF + GIE)

 which will cause the CPU go to sleep. Then the Timer ISR would get lost.

Is this case protected? Will the CPU check for pending interrupts before going to LPM? And in general, is the design presented above ok?

Best Regards,

tml