Yes. Each port contains a sample interrupt driven serial port driver that should be used as an example for your microcontroller architecture.
Bear in mind that the drivers were written for the purpose of testing the context switch from ISR mechanism so are not optimised for speed.
Use the sample serial port drivers as an example - see the FAQ directly above.
See the description of the configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY configuration parameters for additional information.
As downloaded most ports do not implement interrupt nesting - the exceptions being the Cortex M3 and PIC32 ports. In most cases the use of a fast real timer kernel removes the need for interrupts to nest.
Nesting interrupts introduces uncertainty into the stack usage requirements and complicates system behaviour analysis. Instead it is preferred that interrupt handlers do nothing but collect event data, post the data to a task, and clear the interrupt source. This permits the interrupt to exit very promptly by deferring any necessary computational processing of the event data to the task level - inside 'interrupt tasks'. The task level processing can be performed with interrupts enabled, negating the requirement for nesting.
This scheme has the added advantage of flexible event processing prioritisation. Task priorities are used instead of the prioritisation being dependent on the priority assigned to each interrupt source by the target processor. The prioritisation of interrupt handler tasks would normally be chosen to be higher than ordinary tasks within the same application - thereby allowing the interrupt handler to return directly into the peripheral handler task. The interrupt can interrupt a normal task, grab the data, then return to the interrupt handling task. When the interrupt handling task completes, the interrupted task (or whichever task is now the highest priority ready task) will automatically continue from the point at which it was interrupted. Processing of the interrupt routine itself and the interrupt handler task will be contiguous in time just as if all the processing had been performed in the interrupt itself, but using a much simpler mechanism.
In the case that a very fast interrupt response is required for a certain peripheral then the peripheral priority can normally be set to above that of the kernel itself. This means the processing of the peripheral will never be delayed by the action of the kernel.