I thought I'd follow up to my original post, where I came off sounding very binary, suggesting that solutions can either use polling or interrupts but not discussing any other hybrid approaches. In fact, a hybrid approach is probably a very good solution.
To go back to my analogy about doing homework while also completing Saturday morning chores, there are other options. You could ask your little brother to check the door for a delivery every 30 seconds and tell you when the delivery has arrived or -- even better -- just accept the package and sign for it himself without ever having to bother you. Taking this approach, your dishwashing and laundry chores will be greatly simplified. You'll also be able to apply yourself to your homework much more productively. Getting another person to "poll" for you rather than doing it yourself is much like creating a software task that runs independently of the main code and handles the polling.
If the task has no need to communicate (i.e., share data) with your main code then things are pretty simple. However, when the task needs to send information to the main code (or to any other task(s) that you may have created), or vice-versa, then you need to worry about the potential for the data to become corrupted in the hand-off. These can be really nasty bugs to hunt down because sometimes everything works perfectly and sometimes the code seems to go berserk, where "sometimes" could mean anything from rarely to occasionally to usually to almost always.
There are several different approaches that you can take in FRC for multi-tasking, which is one of a handful of umbrella terms encapsulating a number of related issues. First, beginning in the 2012 season, the WPILib was enhanced to include some new classes that permit you you define sub-systems and commands. As has already been mentioned, the "WPILib Robot
Programming Cookbook" can help instruct you on how to design and implement a software architecture consisting of a set of cooperating subsystems. This document can be downloaded from the
http://firstforge.wpi.edu/sf/sfmain/do/home website (go to the WPILib project).
Second, you can create your own tasks, again using the WPILib. Refer to the "WPI Robotics Library
User’s Guide" PDF document, available from the same place as the cookbook. These tasks can do anything you want. You could, for example, create a task that periodically polls an input for changes in values. You are essentially checking the value of an input inside an infinite loop. Just be sure to insert a wait instruction; otherwise this task will suck up a lot of the CRIO CPU and starve other tasks of CPU time. You could also (or instead) create a task and schedule it to run periodically. This should have the same effect as the infinite loop approach, but is arguably cleaner since the task just contains the code to check the input, does away with the infinite loop and instead lets an operating system timer repeatedly call the task at a regular time interval.
Third, you can define and register interrupt handlers for analog outputs and for digital inputs and outputs. I have no experience with these but you can check the WPILib API (I'm looking at the C++ API available at
http://www.virtualroadside.com/WPILib/index.html).
Fourth, just as you can create WPI tasks (above), you can also go straight to the VxWorks operating system (applies to C++; not sure about Java) and create VxWorks OS tasks. Consult the "WindRiver VxWorks Kernel Programmer's Guide" for details on how to setup and use such tasks. VxWorks documentation can be difficult to come by but I have seen it on the web. Failing that, perhaps if you explain that you are a FRC team programmer, you might be able to email the good folks at WindRiver's support web site and see whether they might help you out with some VxWorks documents for the OS version applicable to FRC.
Finally, you *might* also be able to write code that connects to interrupts at the the operating system level. I'm not sure about this, as this might be "firewalled" (for lack of a better term) by the way the WPI CRIO image routes inputs and outputs through the FPGA. I'm sure there are a few people out there that can answer this.
Reading all the documentation and blog posts about how to program your robot is daunting. And it can often be confusing trying to see the big picture when people are talking online about so many various techniques. Sometimes you just need explained that the online cacophony represents a witch's brew of alternative solutions rather than pieces of the one-and-only way to do it.