7.5. Blocking System Calls

A single threaded or a multi threaded application may have a thread block on a system call, thereby delaying the update. This is particularly problematic for multi-threaded applications since one thread blocking on a system call may indefinitely delay the update of the code of another thread. That's because all threads need to be blocked by our system to update and we cannot tell how long a thread will block on a system call. Examples include waiting to read user input, waiting to receive data from a network socket, or writing to a file on disk. This indefinite blocking possibility exists because the thread waits to acquire a lock, or is put to sleep on a queue inside the operating system kernel. We aim to provide an updating solution that does not rely on the operating system and as such refrain from instrumenting lock acquisition and release inside the kernel.

Access to an I/O file descriptor can be requested as non-blocking when first opening the descriptor. We automatically transform applications to always open() file descriptors as non-blocking and subsequent read()/write(),send()/recv(),select() operations can be issued in polling loops allowing for immediate updates. We also support creating non-blocking file descriptors with pipe(). The blocking calls that are not yet supported include pselect(),recvfrom(),recvmsg(), and creat().

The polling loop wait period defaults at 10000 microseconds. It can be customized by passing the --polling-microseconds=<new_value> to the UpStare compiler.

There are plans to automatically segment the write(), send(), and sendfile() operations to smaller chunks to ensure the system call won't block indefinitely.