Understanding Wire.requestFrom() timing

When requesting data from an I2C device using the Wire library, when does Wire.requestFrom() stop blocking and move on to the next line?
Is it immediately after sending the request;
or does it only move on after all requested bytes are received from the slave
or when Wire.setTimeout() or a default delay have expired?

In the example below,
Example from Wire - Arduino Reference

#include <Wire.h>

void setup()
{
  Wire.begin();        // join i2c bus (address optional for master)
  Serial.begin(9600);  // start serial for output
}

void loop()
{
  Wire.requestFrom(2, 6);    // request 6 bytes from slave device #2.  Does this line block until 6 bytes are received?  
//If not, how long does it block for?  
//Is the duration equal to Wire.setTimeout(time)?
// If the above line returns immediately after sending the request, it is very plausible that the target I2C device will not have had time to send anything before the next line is executed.
  while(Wire.available())    // slave may send less than requested
  { 
    char c = Wire.read();    // receive a byte as character
    Serial.print(c);         // print the character
  }

  delay(500);
}

Reason for asking: when I request 32 bytes, I need exactly 32 bytes before I overwrite my existing valid data. Will the following code reliably grab every stream of 32 valid registers from 12-44?

#include <Wire.h>
uint8_t registerBuffer[32];
void setup()
{
Wire.begin();
Serial.begin(9600); 
}
void loop()
{
  if(getBlockOfRegisters(0x40, 12, 32, registerBuffer))
  {
    // do stuff with the data
  }
  delay(500);
}

boolean getBlockOfRegisters(int i2c_addr, int firstRegister, int numRegisters, uint8_t *buffer)
{
  int error_code;
  boolean data_valid = false;
    Wire.beginTransmission(i2c_addr);                              
    Wire.write(firstRegister);               
    error_code  = Wire.endTransmission();    
    if ( error_code )
    {
         Serial.print( "i2c set register error : " );
         Serial.println(error_code);
    } 
    Wire.requestFrom(i2c_addr, numRegisters);
    if(Wire.available() == numRegisters)    
    { 
       data_valid = true;
       for(int i = numRegisters-1 ; i >= 0 ; i--)
        { buffer[i] = Wire.read();}   
    }    
    else
    { 
        Serial.print( "i2c data invalid: " ); 
        Serial.print( Wire.available());
        Serial.print(" received instead of ");
        Serial.print(numRegisters);
    } 
    return ( data_valid );
}

Bump. Come on, someone must know. The I2C protocol allows any number of bytes to be sent between start and stop conditions. So what is the behavior of Wire.available if the message length exceeds the buffer length of 32 bytes? If it is undefined, that really sucks.
slomobile

slomobile:
The I2C protocol allows any number of bytes

I don't know the answer to your question, but I don't think you can pass any number of bytes. 32 is the max according to this article.

ScottG:
I don't know the answer to your question, but I don't think you can pass any number of bytes. 32 is the max according to this article.
Gammon Forum : Electronics : Microprocessors : I2C - Two-Wire Peripheral Interface - for Arduino

I was aware of the 32 byte buffer. I had assumed it was a FIFO buffer, is it not? According to http://www.nxp.com/documents/other/39340011.pdfpage 10
The I2C-bus specification
7 TRANSFERRING DATA
7.1 Byte format
Every byte put on the SDA line must be 8-bits long. The
number of bytes that can be transmitted per transfer is
unrestricted. Each byte has to be followed by an
acknowledge bit. Data is transferred with the most
significant bit (MSB) first (see Fig.6). If a slave can’t
receive or transmit another complete byte of data until it
has performed some other function, for example servicing
an internal interrupt, it can hold the clock line SCL LOW to
force the master into a wait state. Data transfer then
continues when the slave is ready for another byte of data
and releases clock line SCL.
... If a master-receiver is involved in a transfer, it must signal
the end of data to the slave- transmitter by not generating
an acknowledge on the last byte that was clocked out of
the slave. The slave-transmitter must release the data line
to allow the master to generate a STOP or repeated
START condition.

Given that, there should be a way for Arduino master-receiver to NACK the last byte which fills the buffer, then once SDA is released and the buffer is empty, generate a repeated start and request the next 32 bytes.

Your at a level beyond me, but your issue is mentioned a bit in this article: DssCircuits.com is for sale | HugeDomains
Search for NACK and it will take you to a paragraph that talks a little bit about this. Maybe the author can give you some insight since he wrote an I2C library.

slomobile:
When requesting data from an I2C device using the Wire library, when does Wire.requestFrom() stop blocking and move on to the next line?
Is it immediately after sending the request;
or does it only move on after all requested bytes are received from the slave

When the requested data has fully arrived, or the request cannot be satisfied. I'm not sure about a time-out, I think the default library expects to get the ACK or NAK, so it might not time out. Bear in mind that because of the way the protocol is implemented, if the receiving device does not respond, that counts as a NAK.

There have been reports of the Wire library hanging the sketch if certain interrupts are not received.

slomobile:
So what is the behavior of Wire.available if the message length exceeds the buffer length of 32 bytes? If it is undefined, that really sucks.

The master can NAK the response at any time, once it has got enough bytes of response (effectively, the number you requested) so I suspect that if you request more than 32 it will NAK on the 32nd.

slomobile:
I was aware of the 32 byte buffer. I had assumed it was a FIFO buffer, is it not?

I don't think so. You can increase the buffer size by changing two defines. Most devices I've seen don't expect you to have huge buffers, because they are designed for small chips.

Thank you Nick! Your site is by far the best compilation of useful material for communication protocols on Arduino that I have seen. I'll be spending the day reading your whole site and trying out some of your code. If I cannot do what I need with Wire and your I2C_Anything library, I might try my hand at writing an Arduino I2C library syntactically similar to mbed I2C so that drivers written for mbed may more easilly be translated to Arduino.