It returns to where the interrupt occurred, executes one more instruction (machine code instruction, not "line of C"), and then either services the next (queued) interrupt or continues running from that point.

Since you wrote "or after the attach interrupt line?" , I think you are expecting interrupt immediately after the attachInterrupt() call. That can happen if either of following is true:1. Before attaching, you did not clear any pending interrupt at NVIC (Nested Vector Int Controller) AND there was an interrupt pending, So, it makes sense to clear such stray ints beforehand.2. You programmed your device to interrupt before issuing attachInterrupt().

As far as where it resumes after interrupt, remember the rule James C4S said.

For time critical apps you need to compare timings of different things. The DUE runs at 84 MHz => Cycle Time = 11.905 nanoseconds (worst case w/o considering pipeline, pre-fetch, etc.). Most assembly instructions (machine codes) on DUE executes in 1 to 2 cycles. So, in 1 microsecond, the cpu executes roughly 55 such assembly codes.

The moment your device raises the interrupt, it will not register to the cpu at that same femtosecond! I suspect a bunch of nanoseconds would pass before your first line of ISR (interrupt service routine) executes EVEN IF THE CPU WAS NOT EXECUTING ANY HIGHER PRIORITY ISR. That is interrupt latency. Not sure what it is for DUE. Needs a scope, a test program and some well-placed wires between DUE, scope and your device.

So, if your vibes are spaced microseconds apart and that's what you want to capture using ISR, the DUE may not cut it. You need much faster cpu. A typical compiler would produce 3-15 assembly instructions per C line. So, a 10 line C-level ISR can amount to 2 microseconds of execution time.

You can take a look into the scheduler code. Everything is open source in Arduino. Then the timing details would emerge.Hope this helps.