ler. This means that Pf2 collects samples of program execution periodically, instead of tracing every action (e.g. method invocations and returns). Pf2 uses the rb_pro fi le_thread_frames() API for sampling. When to do so is controlled by Schedulers, described in the following section. Schedulers Schedulers determine when to execute sample collection, based on con fi guration (time mode and interval). Pf2 has two schedulers available. SignalScheduler (Linux-only) The fi rst is the SignalScheduler, based on POSIX timers. Pf2 will use this scheduler when possible. SignalScheduler creates a POSIX timer for each Ruby Thread (the underlying pthread to be more accurate) using timer_create(3). This leaves the actual time-keeping to the OS, which is capable of tracking accurate per-thread CPU time usage. When the speci fi ed interval has arrived (the timer has expired), the OS delivers us a SIGALRM (note: Unlike setitimer(2), timer_create(3) allows us to choose which signal to be delivered, and Pf2 uses SIGALRM regardless of time mode). This is why the scheduler is named SignalScheduler. Signals are directed to Ruby Threads' underlying pthread, effectively "pausing" the Thread's activity. This routing is done using SIGEV_THREAD_ID, which is a Linux-only feature. Sample collection is done in the signal handler, which is expected to be more accurate, capturing the paused Thread's activity. This scheduler heavily relies on Ruby's 1:N Thread model (1 Ruby Threads is strongly tied to a native pthread). It will not work properly in MaNy (RUBY_MN_THREADS=1). TimerThreadScheduler Another scheduler is the TimerThreadScheduler, which maintains a time-keeping thread by itself. A new native thread (pthread on Linux/macOS) will be created, and an in fi nite loop will be run inside. After sleep(2)-ing for the speci fi ed interval time, sampling will be queued using Ruby's Postponed Job API. This scheduler is wall-time only, and does not support CPU-time based pro fi ling.