[Ether]

An event handler, as I was using the phrase, is application-level code that gets executed when an external asynchronous hardware event occurs. The execution of this code is "managed" by LabVIEW/vxworks in the sense that resources are allocated to the handler based on time-sharing and priority of other tasks concurrently competing for resources.

The 2010 FRC LabVIEW Framework had explicit support for periodic tasks. These periodic tasks are time-based, not event-based. You could put code in there to poll for an external event of interest. You could even change the default 10ms task to 1ms, although that would waste CPU resources if the event you're polling for occurs much less frequently than that.

I don't know what "Asynchronous VIs that wait for a condition" are, but that sure sounds like what I have in mind when I use the phrase "event handler". Perhaps the 2011 Framework could include a shell or template for something like that, as was done for the periodic tasks, to make it more accessible.

I make a distinction between "interrupt service" code and "event handler" code. To me, "interrupt service" is what happens from the time the interrupt occurs until the code ACKs the interrupt (if required by the hardware) and re-enables global interrupts. During this period everything else is locked out: There is no concurrency management (time sharing) because there is no concurrency. I'll go out on a limb here and say that for the purposes of FRC programming, interrupts should be serviced ONLY by LabVIEW/vxworks/FPGA: There should be NO need for teams to be writing their own interrupt service code.

So when I see a poster asking "how to use interrupts" two thoughts come to mind: 1) what is this team doing that is so time-critical that it cannot properly be handled in a fast periodic task, and 2) do they really mean they want to write an interrupt service routine, or do they want to write an event handler.