My 8-bit RTOS experience is this, ...

An interrupt will call an ISR just like in OS-less case and this ISR belong to you, the author of the project. You can do whatever you want in the ISR, however the interrupt may (should?) be of interest to the system as a whole. If the interrupt is an event that a dormant task is waiting on, then a method is typically available so that the ISR can notify the waiting task upon completion of the ISR. It's typically a couple of lines of code such that the RTI at the end of the ISR causes the context switch to the dormant task.

Running Task -> IRQ -> Your ISR -> 
   Common Exit Stub -> Scheduler swaps context pointer -> 
      RTI -> Dormant task runs

You only have to invoke the RTOS if you want to, but you really should if you are properly designing the system using the RTOS.

So if uSec timing is critical in your ISR, you can buffer incoming data (for example) then signal a semaphore that tells the task waiting on this data that there is data. The task that was waiting on the data may have been in a wait-on-queue-empty condition and now becomes runnable because the queue is no longer empty. If that task is now the highest priority runnable task, it will run. The buffering and queue are likely provided with the RTOS, but you can incorporate your own if you like.

It's really phenomenally cool stuff, but requires a different mindset than non-RTOS design. I can post more about this if you like...

GB