Working With Unix Processes

Working With Unix Processes

Jesse Storimer

Language: English

Pages: 115


Format: PDF / Kindle (mobi) / ePub

A crash course in Unix programming for the uninitiated. Working With Unix Processes (WWUP for short) is a look at programming with the building blocks of a Unix system, something that's been done for decades. WWUP is the only book addressing Unix programming specifically for the modern web developer.

Learn the semantics of powerful concepts like forking, signals, file descriptors, daemon processes, and more.

With the included appendices you'll learn how popular Ruby projects are using these concepts to drive thousands of applications. These take the concepts presented and put them in a real-world context.

There are lots of great resources available on this topic for free on the web, so why does this book exist? This book is a short, to-the-point introduction written specifically for the modern web developer. All of the examples in the book are written in Ruby, no C programming required. Even though it's Ruby, anyone with experience in a high-level language should feel right at home.



















Signals There is a way to preserve handlers defined by other Ruby code, so that your signal handler won't trample any other ones that are already defined. It looks something like this: trap(:INT) { puts 'This is the first signal handler' } old_handler = trap(:INT) { puts 'This is the second handler' exit } sleep 10 # so that we have time to send it a signal Just send it a Ctrl-C to see the effect. Both signal handlers are called. Now let's see if we can preserve the system

by re-executing itself for a zero-downtime restart. It responds to the TTIN signal by incrementing the number of worker processes it has running. See for a full list of the signals it supports and how it responds to them. The memprof project has a good example of being a friendly citizen when handling signals. System Calls Ruby's Process.kill maps to kill(2), Kernel#trap maps roughly to sigaction(2). signal(7) is also useful. Daemon Processes

control. By 'job control' I'm referring to the way that processes are handled by the terminal. We begin with process groups. Each and every process belongs to a group, and each group has a unique integer id. A process group is just a collection of related processes, typically a parent process and its children. However you can also group your processes arbitrarily by setting their group id using Process.setpgrp(new_group_id). Have a look at the output from the following snippet. puts

it should always come back to that nice baseline. Doesn't the GC clean up for us? Well, yes, but it doesn't do a great job. It does an OK job. The truth is that MRI's GC has a hard time releasing memory that it doesn't need anymore. When the Ruby VM boots up it is allocated a certain block of main memory by the kernel. When it uses up all that it has it needs to ask for another block of main memory from the kernel. Due to numerous issues with Ruby's GC (naive approach, disk

get the information for each exited child when it's ready for it. Take note that calling any variant of Process.wait when there are no child processes will raise Errno::ECHILD. It's always a good idea to keep track of how many child processes you have created so you don't encounter this exception. In the Real World The idea of looking in on your child processes is at the core of a common Unix programming pattern. The pattern is sometimes called babysitting processes, master/worker, or

Download sample