understanding interrupt vector, interrupt handler, and interrupts

>>It's used to allow the processor to continue doing other functions while waiting for hardware instead of >>sitting in a polling loop.

Can you elaborate on this part? I am not clear what you mean by waiting for hardware

Sure. Modern operating systems support multiple processes (programs, services,...) running simultaneously. When one of these processes makes a request that involves a piece of hardware, such as reading a block from a file on disk, there will be a delay waiting for the hardware to complete the request. Rather than waiting for the request to complete, the operating system marks the requesting process as blocked waiting for I/O to complete, and allows other processes to continue running, waiting for the disk controller to send an interrupt when the request is completed. The interrupt vector points to interrupt handler in the OS that completed the read request. At this point, the process scheduling logic in the OS usually kicks in, and the requesting process is typically made the running process again. This scheduling also happens when the hardware clock interrupt comes in (handled just like any interrupt)l, giving the OS a chance to share the CPU across all runnable processes at regular intervals in a multitasking environment.

There are other models for handling hardware requests. Older OS's like Microsft DOS (and if you remember CP/M) do not support multitasking; when a program makes a hardware request, the computer waits until it finishes. That doesn't translate very well to multitasking, since an I/O request from one process would stall all processes while the OS polls the hardware waiting for the request to complete.