user4478: In general, what's the maximum length of instructions that can be included in an Interrupt Service Routine?
The docs say an ISR should be "as short and fast as possible", but that's bit vague.
For example, I have an ISR that gets called for each pulse on an motor's encoder.
void on_encoder_pulse(){
    encoder_change = true;
    count1 += 1;
    count2 += last_call;
    last_call = millis();
}

Will this run without interruption?

user3917: In general, on AVR devices, interrupts have been turned off (by hardware) when an ISR (interrupt service routine) begins execution.
Thus, if on_encoder_pulse() is an ISR and is invoked due to an interrupt,  it will run uninterrupted.
An ISR that within itself turns the interrupt system back on before it's done runs the risk of other interrupts being serviced before it completes.
The suggestion that ISR's be “as short and fast as possible” is intended to avoid other interrupts being missed, as will happen if an interrupt source activates multiple times while the interrupt system is off.  Most interrupt sources latch a bit and will be handled when the interrupt system is re-enabled; some don't latch a bit, and won't be seen if some ISR is long-winded.

user7508: As already explained by jwpat7, interrupts are, by default, not
interruptible. Thus, if another interrupt fires while your ISR is
running, it will no be serviced until your ISR completes. This delay you
impose on other interrupts is called latency. So your question boils
down to “how much latency can the other interrupts tolerate”.
There is no simple answer: it all depends on the timing requirements
of whatever those interrupts are servicing. For example:

The millis() counter is updated by interrupts. Any latency longer
than 1024 µs (on the Uno) can make it loose tics.
If you are using the serial port to receive data, a latency longer
than one byte time (1040 µs at 9600 pbs, less at higher baud
rates) will make you loose data.
If you are using the Servo library, any interrupt latency will
create jitter in the drive signal, and at some point this may become
visible as mechanical jitter.

Then, if you really need a precise answer, you will have to check the
timing requirements of every piece of hardware and every library you
are using. And then check the latency already imposed by the ISRs in
those libraries, as your latency can come in top of that.
If your program relies on loop() looping fast enough, you should also
keep in mind that interrupts also slow that.

user13432: 
What is the maximum length an Interrupt Service Routine?

This depends on the max latency before servicing any other waiting Interrupt Service Routine (ISR). 
An AVR ISR will execute with further interrupts disabled until the running ISR is completed. Any other interrupt(s) during the execution will be delayed. Data may be lost if the delay is too long. This depends on the interrupt source and frequency of interrupts. 
In general an ISR (for incoming data) should only capture the data that could be lost and delay processing to the main loop function. A good example is the ISR for the Arduino Hardware Serial (USART) handling. Data sent and received are queued. 
A traditional method (design pattern) is to have very short ISRs that capture data and push to an event queue. All processing is done in the main loop. This gives short latency and faster response, and reduces the risk of ISRs depending on each other, etc.
Cheers!

4478: <p>In general, what's the maximum length of instructions that can be included in an Interrupt Service Routine?</p>

<p><a href="https://www.arduino.cc/en/Reference/AttachInterrupt" rel="nofollow">The docs</a> say an ISR should be "as short and fast as possible", but that's bit vague.</p>

<p>For example, I have an ISR that gets called for each pulse on an motor's encoder.</p>

<pre><code>void on_encoder_pulse(){
    encoder_change = true;
    count1 += 1;
    count2 += last_call;
    last_call = millis();
}
</code></pre>

<p>Will this run without interruption?</p>
 3917: <p>In general, on AVR devices, interrupts have been turned off (by hardware) when an ISR (interrupt service routine) begins execution.</p>

<p>Thus, if <code>on_encoder_pulse()</code> is an ISR and is invoked due to an interrupt,  it will run uninterrupted.</p>

<p>An ISR that within itself turns the interrupt system back on before it's done runs the risk of other interrupts being serviced before it completes.</p>

<p>The suggestion that ISR's be “as short and fast as possible” is intended to avoid other interrupts being missed, as will happen if an interrupt source activates multiple times while the interrupt system is off.  Most interrupt sources latch a bit and will be handled when the interrupt system is re-enabled; some don't latch a bit, and won't be seen if some ISR is long-winded.</p>
 7508: <p>As already explained by jwpat7, interrupts are, by default, not
interruptible. Thus, if another interrupt fires while your ISR is
running, it will no be serviced until your ISR completes. This delay you
impose on other interrupts is called <em>latency</em>. So your question boils
down to “<em>how much latency can the other interrupts tolerate</em>”.</p>

<p>There is no simple answer: it all depends on the timing requirements
of whatever those interrupts are servicing. For example:</p>

<ul>
<li>The <code>millis()</code> counter is updated by interrupts. Any latency longer
than 1024&nbsp;µs (on the Uno) can make it loose tics.</li>
<li>If you are using the serial port to receive data, a latency longer
than one byte time (1040&nbsp;µs at 9600&nbsp;pbs, less at higher baud
rates) will make you loose data.</li>
<li>If you are using the Servo library, <em>any</em> interrupt latency will
create jitter in the drive signal, and at some point this may become
visible as mechanical jitter.</li>
</ul>

<p>Then, if you really need a precise answer, you will have to check the
timing requirements of <em>every</em> piece of hardware and <em>every</em> library you
are using. And then check the latency already imposed by the ISRs in
those libraries, as your latency can come in top of that.</p>

<p>If your program relies on <code>loop()</code> looping fast enough, you should also
keep in mind that interrupts also slow that.</p>
 13432: <blockquote>
  <p>What is the maximum length an Interrupt Service Routine?</p>
</blockquote>

<p>This depends on the max latency before servicing any other waiting Interrupt Service Routine (ISR). </p>

<p>An AVR ISR will execute with further interrupts disabled until the running ISR is completed. Any other interrupt(s) during the execution will be delayed. Data may be lost if the delay is too long. This depends on the interrupt source and frequency of interrupts. </p>

<p>In general an ISR (for incoming data) should only capture the data that could be lost and delay processing to the main loop function. A good example is the ISR for the Arduino Hardware Serial (USART) handling. Data sent and received are queued. </p>

<p>A traditional method (design pattern) is to have very short ISRs that capture data and push to an event queue. All processing is done in the main loop. This gives short latency and faster response, and reduces the risk of ISRs depending on each other, etc.</p>

<p>Cheers!</p>
