Follow the Australian Telecommunications scene NEWSLETTER- FREE TRIAL
 | |
|
Technology news and Jobs 
The Linux distillery Processed Linux: from exec to exit
The Linux distillery Processed Linux: from exec to exit | Processed Linux: from exec to exit |
|
| by David M Williams | |
| Monday, 03 March 2008 | |
|
Page 2 of 3 vfork is a legacy item. It’s similar to fork except it guarantees that user memory won’t be copied. This is intended to improve performance and efficiency. When I say fork makes a duplicate, I really mean it; everything in the child processes space is exactly like the original with the exception of the fork return code. All the memory contents within the process space it was shoehorned into are duplicated.Featured Whitepaper
5 Best Practices for Smartphone Support
Yet, on the other hand, if the child process doesn’t really need to know any of this, or doesn’t care, then all that memory copying was actually wasteful. Here’s where vfork comes in; it spins off a child process but without the time-expensive memory reads and writes. The init process uses this system call when it creates all its children. There’s no need for any process to have a copy of the user state of init so the kernel developers figured a second system call like vfork would be an efficient alternative for init’s purposes and others like ftpd and inetd/xinetd. In practice, vfork is complex to implement because it makes certain demands on the child process particularly that it uses exec to invoke a command immediately and that this command does not fail. If the spawned off process fails then the results are undefined and hence unpredictable. If you check the vfork man page you’ll find some interesting notes putting it down, including that vork’s actual existence is an unfortunate spectre of the past! All modern Linux and UNIX distros use a technique called copy on write which negates the need for vfork to exist because now the regular fork system call has the efficiency gains that vfork was created to bring about. Copy on write causes the parent and child processes to share physical memory for as long as possible and only copies memory pages when one of the processes actually writes data to memory. If a child process is forked and doesn’t write any memory then you have a big win because no memory copying was required. Even if the child process modifies a small bit of memory there’s a gain because only the modified pages are duplicated. In fact, not only do you save time you also save memory because you just need one physical set of data for two processes, for as long as possible. Consider the gains this gives init and xinetd and other important system functions whose whole purpose is basically to fork and exec. The clone system call is unique to Linux and is a general purpose fork but which allows an application control over which parts of the child process will be shared with the parent. exec, mentioned above, is a fundamental system call. Or rather, it is a family of system calls and which are documented in the exec man page. Several different calls are listed there but these are all wrappers around one, execve. The purpose of execve is to execute a command, or more specifically, to transfer control of your process from one executable program to another. This is why we say init forks and execs; it makes a new child process then uses exec to call up a new program in its place, without harming the original parent process. So, what’s this procfs all about then? Please read on! CONTINUED |
| < Next story in category | Previous story in the category > |
|---|
