OSDev.org

Apparently, part of the POSIX signal interface is timer signals. One might suspect that these would be used for instance by the TCP/IP stack in order to avoid explicit "push" operations. There are other possible uses. POSIX defines these timers with a very high precision, but it is not clear what precision / resolution is required.

But how would these be implemented? In the DOS/BIOS environment, timers where typically using int 8 / 0x1c, and applications would hook these. However, POSIX is in user-space, and I don't think it is a good idea to provide hooks for hardware IRQs in kernel that call user-space. Neither would I allow kernel timers to do callbacks into user-space.

One possible solution would be to start an additional thread at process-creation time that would be responsible for implementing user-space timers, and possibly some other signal-functions as well. The thread would use the existing wait-functions, which are pretty accurate.

How do others implement this?

Signals are like APCs on Windows, and are sent to a specific thread. The normal execution of a thread is interrupted and the signal handler is invoked. You can check for signals before returning to user mode from a hardware interrupt or system call.

Gigasoft wrote:Signals are like APCs on Windows, and are sent to a specific thread. The normal execution of a thread is interrupted and the signal handler is invoked. You can check for signals before returning to user mode from a hardware interrupt or system call.

Yes, but if the usermode code never executes system calls, but only does some lengthy calculation, then timer notifications will never happen (at least not until the thread is preempted). CTRL-C notifications will never happen either. In the latter case, the sender could put the call on the running thread's stack so it gets executed in a timely manner, but for timers this won't work as there is no event happening as a timer expires unless it is a kernel timer.

rdos wrote:

Gigasoft wrote:Signals are like APCs on Windows, and are sent to a specific thread. The normal execution of a thread is interrupted and the signal handler is invoked. You can check for signals before returning to user mode from a hardware interrupt or system call.

Yes, but if the usermode code never executes system calls, but only does some lengthy calculation, then timer notifications will never happen (at least not until the thread is preempted). CTRL-C notifications will never happen either. In the latter case, the sender could put the call on the running thread's stack so it gets executed in a timely manner, but for timers this won't work as there is no event happening as a timer expires unless it is a kernel timer.

rdos, that's precisely what happens. A hw interrupt (from the timer hw) will cause a kernel entry. That entry will expire the timer and the signal can be delivered as the kernel returns to userspace.

If the thread is running on another core then an IPI will be required but the result will be the same