DOCSLIB.ORG

Signals and Inter-Process Communication

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Signals and Inter-Process Communication 2/21/20 COMP 790: OS Implementation COMP 790: OS Implementation Housekeeping Signals and Inter-Process • Paper reading assigned for next class Communication Don Porter 1 2 1 2 COMP 790: OS Implementation COMP 790: OS Implementation Logical Diagram Last time… Binary Memory • We’ve discussed how the OS schedules the CPU Threads Formats Allocators User – And how to block a process on a resource (disk, network) Today’s Lecture System Calls Kernel Process • Today: RCU FileCoordination System Networking Sync – How do processes block on each other? – And more generally communicate? Memory Device CPU Management Drivers Scheduler Hardware Interrupts Disk Net Consistency 3 4 3 4 COMP 790: OS Implementation COMP 790: OS Implementation Outline What is a signal? • Signals • Like an interrupt, but for applications – Overview and APIs – <64 numbers with specific meanings – Handlers – A process can raise a signal to another process or thread – Kernel-level delivery – A process or thread registers a handler function – Interrupted system calls • For both IPC and delivery of hardware exceptions • Interprocess Communication (IPC) – Application-level handlers: divzero, segfaults, etc. – Pipes and FIFOs • No “message” beyond the signal was raised – System V IPC – And maybe a little metadata – Windows Analogs • PID of sender, faulting address, etc. • But platform-specific (non-portable) 5 6 5 6 1 2/21/20 COMP 790: OS Implementation COMP 790: OS Implementation Example Example Pid 300 Pid 300 Pid 400 int main() { int main() { ... ... PC signal(SIGUSR1, &usr_handler); } kill(300, SIGUSR1); ... } int usr_handler() { … Register usr_handler() to handle SIGUSR1 7 Send signal to PID 300 8 7 8 COMP 790: OS Implementation COMP 790: OS Implementation Basic Model Signal Types • Application registers handlers with signal or sigaction • See man 7 signal for the full list: (varies by sys/arch) • Send signals with kill and friends SIGTSTP – 1 – Stop typed at terminal (Ctrl+Z) – Or raised by hardware exception handlers in kernel SIGKILL – 9 – Kill a process, for realzies • Signal delivery jumps to signal handler SIGSEGV – 11 – Segmentation fault – Irregular control flow, similar to an interrupt SIGPIPE – 13 – Broken pipe (write with no readers) SIGALRM – 14 – Timer SIGUSR1 – 10 – User-defined signal 1 SIGCHLD – 17 – Child stopped or terminated SIGSTOP – 19 – Stop a process SIGCONT – 18 – Continue if stopped API names are admittedly confusing 9 10 9 10 COMP 790: OS Implementation COMP 790: OS Implementation Language Exceptions Signal Handler Control Flow • Signals are the underlying mechanism for Exceptions and catch blocks • JVM or other runtime system sets signal handlers – Signal handler causes execution to jump to the catch block 11 From Understanding the Linux Kernel 12 11 12 2 2/21/20 COMP 790: OS Implementation COMP 790: OS Implementation Alternate Stacks Nested Signals • Signal handlers execute on a different stack than • What happens when you get a signal in the signal program execution. handler? – Why? • And why should you care? • Safety: App can ensure stack is actually mapped – And avoid assumptions about application not using space below rsp – Set with sigaltstack() system call • Like an interrupt handler, kernel pushes register state on interrupt stack – Return to kernel with sigreturn() system call – App can change its own on-stack register state! 13 14 13 14 COMP 790: OS Implementation COMP 790: OS Implementation The Problem with Nesting Nested Signals int main() { • The original signal() specification was a total mess! /* ... */ – Now deprecated---do not use! Another signal signal(SIGINT, &handler); • New sigaction() API lets you specify this in detail Double free! delivered on signal(SIGTERM, &handler); return – What signals are blocked (and delivered on sigreturn) /* ... */ PC Calls – Similar to disabling hardware interrupts munmap() } Signal Stack • As you might guess, blocking system calls inside of a int handler() { SIGINT signal handler are only safe with careful use of free(buf1); SIGTERM sigaction() free(buf2); } 15 16 15 16 COMP 790: OS Implementation COMP 790: OS Implementation Application vs. Kernel Example • App: signals appear to be delivered roughly Mark pending immediately … Pid 300 10 signal, • Kernel (lazy): Pid 300 … Pid 400 RUNNINGINTERRUPTIBLE Block onunblock disk – Send a signal == mark a pending signal in the task read! • And make runnable if blocked with TASK_INTERRUPTIBLE flag – Check pending signals on return from interrupt or syscall int main() { • Deliver if pending What happens read(); PC to read? } kill(300, SIGUSR1); int usr_handler() { … 17 Send signal to PID 300 18 17 18 3 2/21/20 COMP 790: OS Implementation COMP 790: OS Implementation Interrupted System Calls Default handlers • If a system call blocks in the INTERRUPTIBLE state, a • Signals have default handlers: signal wakes it up – Ignore, kill, suspend, continue, dump core • Yet signals are delivered on return from a system call – These execute inside the kernel • How is this resolved? • Installing a handler with signal/sigaction overrides • The system call fails with a special error code the default – EINTR and friends • A few (SIGKILL) cannot be overridden – Many system calls transparently retry after sigreturn – Some do not – check for EINTR in your applications! 19 20 19 20 COMP 790: OS Implementation COMP 790: OS Implementation RT Signals Signal Summary • Default signals are only in 2 states: signaled or not • Abstraction like hardware interrupts – If I send 2 SIGUSR1’s to a process, only one may be – Some care must be taken to block other signals delivered – Easy to write buggy handlers and miss EINTR – If system is slow and I furiously hit Ctrl+C over and over, • Understand control flow from application and kernel only one SIGINT delivered perspective • Real time (RT) signals keep a count • Understand basic APIs – Deliver one signal for each one sent 21 22 21 22 COMP 790: OS Implementation COMP 790: OS Implementation Other IPC Pipes • Pipes, Sockets, and FIFOs • Stream of bytes between two processes • System V IPC • Read and write like a file handle • Windows comparison – But not anywhere in the hierarchical file system – And not persistent – And no cursor or seek()-ing – Actually, 2 handles: a read handle and a write handle • Primarily used for parent/child communication – Parent creates a pipe, child inherits it 23 24 23 24 4 2/21/20 COMP 790: OS Implementation COMP 790: OS Implementation Example FIFOs (aka Named Pipes) int pipe_fd[2]; • Existing pipes can’t be opened---only inherited int rv = pipe(pipe_fd); int pid = fork(); – Or passed over a Unix Domain Socket (beyond today’s lec) if (pid == 0) { • FIFOs, or Named Pipes, add an interface for opening close(pipe_fd[1]); //Close unused write end dup2(pipe_fd[0], 0); // Make the read end stdin existing pipes exec(“grep”, “quack”); } else { close (pipe_fd[0]); // Close unused read end … 25 26 25 26 COMP 790: OS Implementation COMP 790: OS Implementation Sockets Select • Similar to pipes, except for network connections • What if I want to block until one of several handles • Setup and connection management is a bit trickier has data ready to read? – A topic for another day (or class) • Read will block on one handle, but perhaps miss data on a second… • Select will block a process until a handle has data available – Useful for applications that use pipes, sockets, etc. 27 28 27 28 COMP 790: OS Implementation COMP 790: OS Implementation Synthesis Example: The Shell Shell Example • Almost all ‘commands’ are really binaries • Ex: ls | grep foo – /bin/ls • Implementation sketch: • Key abstraction: Redirection over pipes – Shell parses the entire string – ‘>’, ‘<‘, and ‘|’implemented by the shell itself – Sets up chain of pipes – Forks and exec’s ‘ls’ and ‘grep’ separately – Wait on output from ‘grep’, print to console 29 30 29 30 5 2/21/20 COMP 790: OS Implementation COMP 790: OS Implementation Job control in a shell Other hints • Shell keeps its own “scheduler” for background processes • Splice(), tee(), and similar calls are useful for • How to: connecting pipes together – Put a process in the background? – Avoids copying data into and out-of application • SIGTSTP handler catches Ctrl-Z • Send SIGSTOP to current foreground child – Resume execution (fg)? • Send SIGCONT to paused child, use waitpid() to block until finished – Execute in background (bg)? • Send SIGCONT to paused child, but block on terminal input 31 32 31 32 COMP 790: OS Implementation COMP 790: OS Implementation System V IPC System V Keys and IDs • Semaphores – Lock • Programmers pick arbitrary 32-bit keys • Message Queues – Like a mail box, “small” messages – Use these keys to name shared abstractions • Shared Memory – particularly useful • Find a key using shmget(), msgget(), etc. – A region of non-COW anonymous memory – Kernel internally maps key to a 32-bit ID – Map at a given address using shmat() • Can persist longer than an application – Must be explicitly deleted – Can leak at system level – But cleared after a reboot 33 34 33 34 COMP 790: OS Implementation COMP 790: OS Implementation Windows Comparison Summary • Hardware exceptions are treated separately from IPC • Understand signals – Upcalls to ntdll.dll (libc equivalent), to call handlers • Understand high-level properties of pipes and other • All IPC types can be represented as handles Unix IPC abstractions – Process termination/suspend/resume signaled with – High-level comparison with Windows process handles – Signals can be an Event handle – Semaphores and Mutexes have handles – Shared memory equally complicated (but still handles) • Single select()-like API to wait on a handle to be signaled 35 36 35 36 6.
Load more

Recommended publications
  • Distributed Programming I (Socket - Nov'09)
    Distributed programming I (socket - nov'09) Warning for programmers network programming is dangerously close to O.S. Network programming: sockets kernel, and therefore: It can easily hang the O.S. verify the results of every operation, without assuming anything as granted Antonio Lioy < [email protected] > APIs can vary in details that are minimal but important consider every possible situation to create english version created and modified by “portable” programs Marco D. Aime < [email protected] > we will try to use Posix 1.g Politecnico di Torino Dip. Automatica e Informatica ISO/OSI, TCP/IP, network programming Exercise – copying data copy the content of file F1 (first parameter on the application command line) into file F2 (second parameter on the 7. application details application command line) user 6. presentation (l6: XDR/XML/... process l5: RPC/SOAP/...) 5. session network programming 4. transport TCP UDP SCTP interface 3. network IPv4, IPv6 kernel communication 2. data link device driver details 1. physical and hardware OSI model IP suite ref. UNP Intro copyfile.c Error messages Error functions must contain at least: best to define standard error reporting functions [ PROG ] program name which accept: [ LEVEL ] error level (info, warning, error, bug) a format string for the error [ TEXT ] error signalling, the most specific as possible a list of parameters to be printed (e.g. input file name and line where the problem has UNP, appendix D.4 (D.3 in 3rd edition) occurred) errno? termination? log level [ ERRNO ] system error number and/or name (if applicable) err_msg no no LOG_INFO err_quit no exit(1) LOG_ERR suggested format: err_ret yes no LOG_INFO err_sys yes exit(1) LOG_ERR ( PROG ) LEVEL - TEXT : ERRNO err_dump yes abort( ) LOG_ERR errlib.h errlib.c © A.Lioy - Politecnico di Torino (2009) B-1 Distributed programming I (socket - nov'09) stdarg.h stdarg.h usage example variable list of arguments (ANSI C) create a function named my_printf declared with an ellipsis (.
    [Show full text]
  • A Practical UNIX Capability System
    A Practical UNIX Capability System Adam Langley <[email protected]> 22nd June 2005 ii Abstract This report seeks to document the development of a capability security system based on a Linux kernel and to follow through the implications of such a system. After defining terms, several other capability systems are discussed and found to be excellent, but to have too high a barrier to entry. This motivates the development of the above system. The capability system decomposes traditionally monolithic applications into a number of communicating actors, each of which is a separate process. Actors may only communicate using the capabilities given to them and so the impact of a vulnerability in a given actor can be reasoned about. This design pattern is demonstrated to be advantageous in terms of security, comprehensibility and mod- ularity and with an acceptable performance penality. From this, following through a few of the further avenues which present themselves is the two hours traffic of our stage. Acknowledgments I would like to thank my supervisor, Dr Kelly, for all the time he has put into cajoling and persuading me that the rest of the world might have a trick or two worth learning. Also, I’d like to thank Bryce Wilcox-O’Hearn for introducing me to capabilities many years ago. Contents 1 Introduction 1 2 Terms 3 2.1 POSIX ‘Capabilities’ . 3 2.2 Password Capabilities . 4 3 Motivations 7 3.1 Ambient Authority . 7 3.2 Confused Deputy . 8 3.3 Pervasive Testing . 8 3.4 Clear Auditing of Vulnerabilities . 9 3.5 Easy Configurability .
    [Show full text]
  • Job Scheduling for SAP® Contents at a Glance
    Kees Verruijt, Arnoud Roebers, Anjo de Heus Job Scheduling for SAP® Contents at a Glance Foreword ............................................................................ 13 Preface ............................................................................... 15 1 General Job Scheduling ...................................................... 19 2 Decentralized SAP Job Scheduling .................................... 61 3 SAP Job Scheduling Interfaces .......................................... 111 4 Centralized SAP Job Scheduling ........................................ 125 5 Introduction to SAP Central Job Scheduling by Redwood ... 163 6Installation......................................................................... 183 7 Principles and Processes .................................................... 199 8Operation........................................................................... 237 9Customer Cases................................................................. 281 The Authors ........................................................................ 295 Index .................................................................................. 297 Contents Foreword ............................................................................................... 13 Preface ................................................................................................... 15 1 General Job Scheduling ...................................................... 19 1.1 Organizational Uses of Job Scheduling ..................................
    [Show full text]
  • Beej's Guide to Unix IPC
    Beej's Guide to Unix IPC Brian “Beej Jorgensen” Hall [email protected] Version 1.1.3 December 1, 2015 Copyright © 2015 Brian “Beej Jorgensen” Hall This guide is written in XML using the vim editor on a Slackware Linux box loaded with GNU tools. The cover “art” and diagrams are produced with Inkscape. The XML is converted into HTML and XSL-FO by custom Python scripts. The XSL-FO output is then munged by Apache FOP to produce PDF documents, using Liberation fonts. The toolchain is composed of 100% Free and Open Source Software. Unless otherwise mutually agreed by the parties in writing, the author offers the work as-is and makes no representations or warranties of any kind concerning the work, express, implied, statutory or otherwise, including, without limitation, warranties of title, merchantibility, fitness for a particular purpose, noninfringement, or the absence of latent or other defects, accuracy, or the presence of absence of errors, whether or not discoverable. Except to the extent required by applicable law, in no event will the author be liable to you on any legal theory for any special, incidental, consequential, punitive or exemplary damages arising out of the use of the work, even if the author has been advised of the possibility of such damages. This document is freely distributable under the terms of the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License. See the Copyright and Distribution section for details. Copyright © 2015 Brian “Beej Jorgensen” Hall Contents 1. Intro................................................................................................................................................................1 1.1. Audience 1 1.2. Platform and Compiler 1 1.3.
    [Show full text]
  • POSIX Signals
    CSE 410: Systems Programming POSIX Signals Ethan Blanton Department of Computer Science and Engineering University at Buffalo Introduction Signals Blocking Concurrency Sending Signals Summary References POSIX Signals POSIX signals are another form of interprocess communication. They are also a way to create concurrency in programs. For these two reasons, they are rather complicated and subtle! Signals provide a simple message passing mechanism. © 2018 Ethan Blanton / CSE 410: Systems Programming Introduction Signals Blocking Concurrency Sending Signals Summary References Signals as Messages POSIX signals are asynchronous messages. Asynchronous means that their reception can occur at any time.1 The message is the reception of the signal itself. Each signal has a number, which is a small integer. POSIX signals carry no other data. 1Almost. We’ll see how to control it later. © 2018 Ethan Blanton / CSE 410: Systems Programming Introduction Signals Blocking Concurrency Sending Signals Summary References Signal Types There are two basic types of POSIX signals: Reliable signals Real-time signals Real-time signals are much more complicated. In particular, they can carry data. We will discuss only reliable signals in this lecture. © 2018 Ethan Blanton / CSE 410: Systems Programming Introduction Signals Blocking Concurrency Sending Signals Summary References Asynchronous Reception From the point of view of the application: Signals can be blocked or ignored Enabled signals may be received between any two processor instructions A received signal can run a user-defined function called a signal handler This means that enabled signals and program code must very carefully manipulate shared or global data! © 2018 Ethan Blanton / CSE 410: Systems Programming Introduction Signals Blocking Concurrency Sending Signals Summary References Signals POSIX defines a number of signals by name and number.
    [Show full text]
  • Programming with POSIX Threads II
    Programming with POSIX Threads II CS 167 IV–1 Copyright © 2008 Thomas W. Doeppner. All rights reserved. Global Variables int IOfunc( ) { extern int errno; ... if (write(fd, buffer, size) == –1) { if (errno == EIO) fprintf(stderr, "IO problems ...\n"); ... return(0); } ... } CS 167 IV–2 Copyright © 2008 Thomas W. Doeppner. All rights reserved. Unix was not designed with multithreaded programming in mind. A good example of the implications of this is the manner in which error codes for failed system calls are made available to a program: if a system call fails, it returns –1 and the error code is stored in the global variable errno. Though this is not all that bad for single-threaded programs, it is plain wrong for multithreaded programs. Coping • Fix Unix’s C/system-call interface • Make errno refer to a different location in each thread – e.g. #define errno __errno(thread_ID) CS 167 IV–3 Copyright © 2008 Thomas W. Doeppner. All rights reserved. The ideal way to solve the “errno problem” would be to redesign the C/system-call interface: system calls should return only an error code. Anything else to be returned should be returned via result parameters. (This is how things are done in Windows NT.) Unfortunately, this is not possible (it would break pretty much every Unix program in existence). So we are stuck with errno. What can we do to make errno coexist with multithreaded programming? What would help would be to arrange, somehow, that each thread has its own private copy of errno. I.e., whenever a thread refers to errno, it refers to a different location from any other thread when it refers to errno.
    [Show full text]
  • UNIT: 4 DISTRIBUTED COMPUTING Introduction to Distributed Programming
    UNIT: 4 DISTRIBUTED COMPUTING Introduction To Distributed Programming: • Distributed computing is a model in which components of a software system are shared among multiple computers. Even though the components are spread out across multiple computers, they are run as one system. This is done in order to improve efficiency and performance. • Distributed computing allows different users or computers to share information. Distributed computing can allow an application on one machine to leverage processing power, memory, or storage on another machine. Some applications, such as word processing, might not benefit from distribution at all. • In parallel computing, all processors may have access to a shared memory to exchange information between processors. In distributed computing, each processor has its own private memory (distributed memory). Information is exchanged by passing messages between the processors. • Distributed computing systems are omnipresent in today’s world. The rapid progress in the semiconductor and networking infrastructures have blurred the differentiation between parallel and distributed computing systems and made distributed computing a workable alternative to high- performance parallel architectures. • However attractive distributed computing may be, developing software for such systems is hardly a trivial task. Many different models and technologies have been proposed by academia and industry for developing robust distributed software systems. • Despite a large number of such systems, one fact is clear that the software
    [Show full text]
  • Sockets in the Kernel
    Linux Kernel Networking – advanced topics (6) Sockets in the kernel Rami Rosen [email protected] Haifux, August 2009 www.haifux.org All rights reserved. Linux Kernel Networking (6)- advanced topics ● Note: ● This lecture is a sequel to the following 5 lectures I gave in Haifux: 1) Linux Kernel Networking lecture – http://www.haifux.org/lectures/172/ – slides:http://www.haifux.org/lectures/172/netLec.pdf 2) Advanced Linux Kernel Networking - Neighboring Subsystem and IPSec lecture – http://www.haifux.org/lectures/180/ – slides:http://www.haifux.org/lectures/180/netLec2.pdf Linux Kernel Networking (6)- advanced topics 3) Advanced Linux Kernel Networking - IPv6 in the Linux Kernel lecture ● http://www.haifux.org/lectures/187/ – Slides: http://www.haifux.org/lectures/187/netLec3.pdf 4) Wireless in Linux http://www.haifux.org/lectures/206/ – Slides: http://www.haifux.org/lectures/206/wirelessLec.pdf 5) Sockets in the Linux Kernel ● http://www.haifux.org/lectures/217/ – Slides: http://www.haifux.org/lectures/217/netLec5.pdf Note ● Note: This is the second part of the “Sockets in the Linux Kernel” lecture which was given in Haifux in 27.7.09. You may find some background material for this lecture in its slides: ● http://www.haifux.org/lectures/217/netLec5.pdf TOC ● TOC: – RAW Sockets – UNIX Domain Sockets – Netlink sockets – SCTP sockets. – Appendices ● Note: All code examples in this lecture refer to the recent 2.6.30 version of the Linux kernel. RAW Sockets ● There are cases when there is no interface to create sockets of a certain protocol (ICMP protocol, NETLINK protocol) => use Raw sockets.
    [Show full text]
  • Introduction to POSIX Signals
    Introduction to POSIX Signals Michael Jantz Prasad Kulkarni Douglas Niehaus Introduction ● This lab is an introduction to signals in Unix systems. – In it, you will learn about some common uses for signals. – You will also construct a small program that uses signals. ● Unpack the starter code, then make and tag it: – bash> tar zxvf eecs678-signals-lab.tar.gz – cd signals/; make; ctags -R EECS 678 Signals Lab 2 Signals ● A signal is a short message that may be sent to a process or a group of processes. ● The only information given to a process is usually the number identifying the signal; there is no room in standard signals for arguments, a message or other accompanying information. ● Signals serve two main purposes: – To make a process aware that a specific event has occurred. – To cause a process to execute a signal handler function included in its code. EECS 678 Signals Lab 3 Interrupts vs. Signals ● Signals and interrupts are very similar in their behavior ● Important difference: interrupts are sent to the operating system by the hardware, signals are sent to the process by the operating system, or other processes through the OS ● Important similarity: both signals and interrupts associate handlers with asynchronous events which interrupt current processing, thus inserting the handler into current code path ● Signals can thus be thought of as an interrupt in software: – However, note that signals have nothing to do with Soft-IRQs. The name seems related, but these are a method for deferring much of the processing associated with a hardware-interrupt into a less restrictive execution context inside the OS.
    [Show full text]
  • POSIX Signal Handling in Java
    Technical Document Series POSIX Signal Handling in Java POSIX Signal Handling In Java Introduction POSIX signals inform a running process of external events, such as the user wishing to kill the process, or the operating system signaling an impending shutdown, or the process being suspended or reinstated; or the process may have violated a resource constraint, such as excessive CPU usage or attempts to access areas outside its permitted memory space, and is asked to shutdown. In short, POSIX signals serve many different purposes. Some are even up to interpretation, such as the HUP (HangUP) signal, which is commonly used to inform a process that something about its environment has changed and the process should adjust accordingly. Some programs may interpret this to mean that the configuration has changed and needs to be reloaded; or the log file has been moved for archiving purposes and a new one should be started. The use of signals is widespread, especially on Unix-based operating systems, but Java provides no standard interface for a Java application to hear and react to them. This document shows you how to get around this limitation. The Good, the Bad, and the Ugly The good news is that there is a way to intercept POSIX signals and react to them in Java. This would allow your Java program to avoid being killable with ^C (SIGINT), for example, even ignore termination requests from the operating system (SIGTERM). Neither of these is necessarily a good idea, of course, unless you know exactly why you would want to catch these signals and either handle them yourself or ignore them altogether.
    [Show full text]
  • Lecture 14: Paging
    Lecture 14: Paging Fall 2018 Jason Tang Slides based upon Operating System Concept slides, http://codex.cs.yale.edu/avi/os-book/OS9/slide-dir/index.html Copyright Silberschatz, Galvin, and Gagne, 2013 "1 Topics • Memory Mappings! • Page Table! • Translation Lookaside Bu$ers! • Page Protection "2 Memory Mapped • Logical address translated not to memory but some other location! • Memory-mapped I/O (MMIO): hardware redirects read/write of certain addresses to physical device! • For example, on x86, address 0x3F8 usually mapped to first serial port! • Memory-mapped file (mmap): OS redirects read/write of mapped memory region to file on disk! • Every call to read() / write() involves a system call! • Writing to a pointer faster, and OS can translate in the background (also see upcoming lecture) "3 Memory-Mapped File • In Linux, typical pattern is to:! • Open file, using open() function! • Optional: preallocate file size, using ftruncate()! • Create memory mapping, using mmap() function! • Do work, and then release mapping using munmap() function! • Kernel might not write data to disk until munmap() "4 mmap() function void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset) • addr is target address of mapping, or NULL to let kernel decide! • length is number of bytes to map! • prot defines what mapping protection (read-only or read/write)! • flags sets other options! • fd is file descriptor that was returned by open()! • offset is o$set into file specified by fd "5 mmap() example part 1 • See man page for each of these functions
    [Show full text]
  • Installation Guide
    Installation Guide Installation Guide Schrödinger Suite 2011 Schrödinger Press Installation Guide Copyright © 2011 Schrödinger, LLC. All rights reserved. While care has been taken in the preparation of this publication, Schrödinger assumes no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. Canvas, CombiGlide, ConfGen, Epik, Glide, Impact, Jaguar, Liaison, LigPrep, Maestro, Phase, Prime, PrimeX, QikProp, QikFit, QikSim, QSite, SiteMap, Strike, and WaterMap are trademarks of Schrödinger, LLC. Schrödinger and MacroModel are registered trademarks of Schrödinger, LLC. MCPRO is a trademark of William L. Jorgensen. Desmond is a trademark of D. E. Shaw Research. Desmond is used with the permission of D. E. Shaw Research. All rights reserved. This publication may contain the trademarks of other companies. Schrödinger software includes software and libraries provided by third parties. For details of the copyrights, and terms and conditions associated with such included third party software, see the Legal Notices, or use your browser to open $SCHRODINGER/docs/html/third_party_legal.html (Linux OS) or %SCHRODINGER%\docs\html\third_party_legal.html (Windows OS). This publication may refer to other third party software not included in or with Schrödinger software ("such other third party software"), and provide links to third party Web sites ("linked sites"). References to such other third party software or linked sites do not constitute an endorsement by Schrödinger, LLC. Use of such other third party software and linked sites may be subject to third party license agreements and fees. Schrödinger, LLC and its affiliates have no responsibility or liability, directly or indirectly, for such other third party software and linked sites, or for damage resulting from the use thereof.
    [Show full text]