DOCSLIB.ORG

Inter-Process Communication

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Inter-Process Communication ELEC-C7310 Sovellusohjelmointi Lecture 6: Inter-process Communication Risto Järvinen October 14, 2019 Lecture contents This lecture: Different ways processes can affect each other Classic IPC Stevens: ch10 (again), ch15 (except 15.7-15.10), ch16-17 (except internet sockets) Kerrisk: ch22, ch44, ch49-50, ch56-57,60-61 (ch58-59 = internet sockets) Internet sockets are covered in Network Programming course, so they are informative and useful to study, but not required on this course. Next lecture: System V IPC POSIX IPC ELEC-C7310 Sovellusohjelmointi Lecture 6: Inter-process Communication 2/25 Risto Järvinen 14.10.2019 How can one process affect another? Use of same resources (CPU time, memory, I/O bandwidth,..) Fork() and wait()ing for children. Signals. Using same filesystem, shared files and directories. File locks. Memory mapped files (mmap()) Terminals/pseudoterminals. Pipes and sockets. Dedicated IPC mechanisms: Message queues, Shared memory, Semaphores. ELEC-C7310 Sovellusohjelmointi Lecture 6: Inter-process Communication 3/25 Risto Järvinen 14.10.2019 Classic IPC Filesystem and Filelocks. (lect5) Pipes, named and unnamed. (today) Sockets, UNIX-domain and network. (today) Terminals. (lect3) Shared memory via mmap(). (lect3, briefly today) Signals, real-time signals. (lect4, RTS today) Some topics already partially covered. ELEC-C7310 Sovellusohjelmointi Lecture 6: Inter-process Communication 4/25 Risto Järvinen 14.10.2019 Signals Covered before. Basic idea is the have asynchronous notification to the process. Implemented as a function (signal handler) that can be called at any time. Limited usability (few signals, no ordering, may lose signals, etc..) ELEC-C7310 Sovellusohjelmointi Lecture 6: Inter-process Communication 5/25 Risto Järvinen 14.10.2019 POSIX Real-Time Signals (RTS) Extension to signals: More signals. Queueing model, with priorities. Sender is identified. Can deliver data. Doesn’t lose multiple signals, though there is limit on how many times a signal can arrive. ELEC-C7310 Sovellusohjelmointi Lecture 6: Inter-process Communication 6/25 Risto Järvinen 14.10.2019 Real-Time Signals limitations Amount of signals is implementation specific. Standard doesn’t specify whether RTS operation may be used with normal signals. Delivered data is only an integer or a pointer. And a pointer usually has no meaning across processes. Limits available via sysconf() and signal.h: SIGRTMIN to SIGRTMAX, min _POSIX_RTSIG_MAX. _POSIX_SIGQUEUE_MAX, _SC_SIGQUEUE_MAX, RLIMIT_SIGPENDING. ELEC-C7310 Sovellusohjelmointi Lecture 6: Inter-process Communication 7/25 Risto Järvinen 14.10.2019 Real-Time Signals API 1/2 #include <signal.h> int sigqueue(pid_t pid , int sig , const union sigval value); int sigaction( int signum , const struct sigaction ∗act , struct sigaction ∗oldact ); void sa_sigaction( int signum, siginfo_t ∗info , void ∗context ); ”value” is union of integer (int) and pointer (void *). RTS mode handler is defined by setting SA_SIGINFO flag in struct sigaction. ELEC-C7310 Sovellusohjelmointi Lecture 6: Inter-process Communication 8/25 Risto Järvinen 14.10.2019 Real-Time Signals API 2/2 #include <signal .h> i n t sigwaitinfo( const sigset_t ∗set, siginfo_t ∗ info ); i n t sigtimedwait( const sigset_t ∗set, siginfo_t ∗ info , const struct timespec ∗ timeout ); Synchronous reception of signals, no need to write asynchronous handler. Blocks until a signal is received (or timeout occurs). If signal arrives between calls to sigwaitinfo(), it’s handled by the given disposition. To avoid surprises, block signals with sigprocmask(). ELEC-C7310 Sovellusohjelmointi Lecture 6: Inter-process Communication 9/25 Risto Järvinen 14.10.2019 Pipes Mentioned briefly before. Data in from one end, out from the other end. Two types: Unnamed and Named The most common use: stdin/stdout/stderr pipes between processes ”ls | less” type command chaining in shell ELEC-C7310 Sovellusohjelmointi Lecture 6: Inter-process Communication 10/25 Risto Järvinen 14.10.2019 Unnamed pipes API #include <unistd .h> int pipe( int pipefd [2]); FILE ∗popen( const char ∗command , const char ∗ type ); int pclose(FILE ∗stream ); Creates two special file descriptors: fd[0] can be read, fd[1] can be written. Pipe is unidirectional. Two-way communications need two pipes. No name or presense besides the FDs. Popen() wraps pipe creation, forking and exec()ing command. ELEC-C7310 Sovellusohjelmointi Lecture 6: Inter-process Communication 11/25 Risto Järvinen 14.10.2019 Unnamed pipes semantics For communication between processes within same process group: Parent process creates a pipe and gives the other end to the children. Within single process: f.ex. signal handler hack, or between threads. Pipe can hold at least PIPE_BUF bytes. (defined 4kiB on Linux, but actual default maxsize is 1MiB and it’s adjustable.) Read operation: If data in buffer, returns data. If no data, blocks. If other end has been closed, returns remaining data and then returns EOF (0). Write operation: If space in buffer, writes atomically. If not enough, blocks until there is. If other end has closed, returns errno=EPIPE and process receives SIGPIPE. ELEC-C7310 Sovellusohjelmointi Lecture 6: Inter-process Communication 12/25 Risto Järvinen 14.10.2019 Named pipes (FIFO) API int mkfifo( const char ∗pathname, mode_t mode); Pipe that is represented by a special type of file in the filesystem. Named pipe is used like a file; it has access rights, it’s opened with open(), deleted with unlink(). Two-way communication still needs two pipes.. Also command-line utility of the same name. ELEC-C7310 Sovellusohjelmointi Lecture 6: Inter-process Communication 13/25 Risto Järvinen 14.10.2019 Named pipe semantics Usable between unrelated processes. Create with mkfifo(), delete with unlink() Open operation: Open with O_WRONLY blocks until other end has opened it the pipe for reading. Open with O_RDONLY blocks until other end has opened the pipe for writing. Read operation: If data in buffer, returns data. If no data, blocks. If other end has been closed, returns remaining data and then returns EOF (0). Write operation: If space in buffer, writes atomically. If not enough, blocks until there is. If other end has closed, returns errno=EPIPE and process receives SIGPIPE. ELEC-C7310 Sovellusohjelmointi Lecture 6: Inter-process Communication 14/25 Risto Järvinen 14.10.2019 Sockets BSD-derived communication method, basis of Internet communication. We’ll stick to particular type of sockets: UNIX Domain sockets. Actual Internet communication will be covered in S-38.3610. Basic idea: socket is a file descriptor, with a bunch of additional calls. List of ”domains” that Linux supporst on sockets: UNIX Domain, IPv4, IPv6, IPX, Netlink (kernel), X.25/AX.25, Appletalk and mechanisms to access raw frames of ATM and IP. ELEC-C7310 Sovellusohjelmointi Lecture 6: Inter-process Communication 15/25 Risto Järvinen 14.10.2019 Socket semantics 1/2 Sockets also have different types: SOCK_DGRAM is message-based, unreliable, connectionless. ("UDP") SOCK_STREAM is stream-based, reliable, connected. ("TCP") SOCK_RAW provides access to raw protocol frames. SOCK_RDM is message-based, reliable, connectionless. SOCK_SEQPACKET is message-based, reliable, connected. ... ... SOCK_DGRAM and SOCK_STREAM are only commonly available. Others are for specialized protocols, like TIPC (Transparent Inter-Process Communication). ELEC-C7310 Sovellusohjelmointi Lecture 6: Inter-process Communication 16/25 Risto Järvinen 14.10.2019 Socket semantics 2/2 Connectionless server: socket(), bind(), recvfrom()*N, close() Connectionless client: socket(), (bind(),) sendto()*N, close() Connected server: socket(), bind(), listen(), accept(), read/recv/write/send*N, close() Connected client: socket(), (bind(),) connect(), read/recv/write/send*N, close() ELEC-C7310 Sovellusohjelmointi Lecture 6: Inter-process Communication 17/25 Risto Järvinen 14.10.2019 Socket API 1/2 #include <sys/socket .h> i n t socket( i n t domain , i n t type , i n t protocol ); i n t bind( i n t sockfd , const struct sockaddr ∗addr , socklen_t addrlen); i n t listen( i n t sockfd , i n t backlog ); i n t accept ( i n t sockfd , struct sockaddr ∗addr , socklen_t ∗ addrlen); i n t connect( i n t sockfd , const struct sockaddr ∗addr , socklen_t addrlen); ELEC-C7310 Sovellusohjelmointi Lecture 6: Inter-process Communication 18/25 Risto Järvinen 14.10.2019 Socket API 2/2 ssize_t recv( int sockfd , void ∗buf, size_t len, int flags ); ssize_t recvfrom( int sockfd , void ∗buf, size_t len, int flags , struct sockaddr ∗src_addr , socklen_t ∗addrlen ); ssize_t recvmsg( int sockfd , struct msghdr ∗msg, int flags ); ssize_t send( int sockfd , const void ∗buf, size_t len, int flags ); ssize_t sendto( int sockfd , const void ∗buf, size_t len, int flags , const struct sockaddr ∗dest_addr , socklen_t addrlen ); ssize_t sendmsg( int sockfd , const struct msghdr ∗msg , int flags ); sendto(fd,buf,len,flags,NULL,0) equals send(fd,buf,len,flags). send(fd,buf,len,0) equals write(fd,buf,len). ELEC-C7310 Sovellusohjelmointi Lecture 6: Inter-process Communication 19/25 Risto Järvinen 14.10.2019 UNIX Domain Sockets Socket that communicates inside a UNIX system. Can be datagram or stream based. (Or even reliable datagram.) Address is a path, with a file (type = socket). If a regular file of the same name exists, EADDRINUSE. Can do both SOCK_DGRAM and SOCK_STREAM. struct sockaddr_un { unsigned short sun_family; /∗ Address family ∗/ char sun_path[108]; /∗ Path name ∗/ } ; ELEC-C7310 Sovellusohjelmointi Lecture 6: Inter-process Communication 20/25 Risto Järvinen
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]
  • 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]
  • Inter-Process Communication, Analysis, Guidelines and Its Impact on Computer Security
    The 7th International Conference for Informatics and Information Technology (CIIT 2010) INTER-PROCESS COMMUNICATION, ANALYSIS, GUIDELINES AND ITS IMPACT ON COMPUTER SECURITY Zoran Spasov Ph.D. Ana Madevska Bogdanova T-Mobile Macedonia Institute of Informatics, FNSM Skopje, Macedonia Skopje, Macedonia ABSTRACT Finally the conclusion will offer a summary of the available programming techniques and implementations for the In this paper we look at the inter-process communication Windows platforms. We will note the security risks and the (IPC) also known as inter-thread or inter-application best practices to avoid them. communication from other knowledge sources. We will look and analyze the different types of IPC in the Microsoft II. INTER -PROCESS COMMUNICATION (IPC) Windows operating system, their implementation and the usefulness of this kind of approach in the terms of Inter-Process Communication (IPC) stands for many communication between processes. Only local techniques for the exchange of data among threads in one or implementation of the IPC will be addressed in this paper. more processes - one-directional or two-directional. Processes Special emphasis will be given to the system mechanisms that may be running locally or on many different computers are involved with the creation, management, and use of connected by a network. We can divide the IPC techniques named pipes and sockets. into groups of methods, grouped by their way of This paper will discuss some of the IPC options and communication: message passing, synchronization, shared techniques that are available to Microsoft Windows memory and remote procedure calls (RPC). We should programmers. We will make a comparison between Microsoft carefully choose the IPC method depending on data load that remoting and Microsoft message queues (pros and cons).
    [Show full text]
  • An Introduction to Linux IPC
    An introduction to Linux IPC Michael Kerrisk © 2013 linux.conf.au 2013 http://man7.org/ Canberra, Australia [email protected] 2013-01-30 http://lwn.net/ [email protected] man7 .org 1 Goal ● Limited time! ● Get a flavor of main IPC methods man7 .org 2 Me ● Programming on UNIX & Linux since 1987 ● Linux man-pages maintainer ● http://www.kernel.org/doc/man-pages/ ● Kernel + glibc API ● Author of: Further info: http://man7.org/tlpi/ man7 .org 3 You ● Can read a bit of C ● Have a passing familiarity with common syscalls ● fork(), open(), read(), write() man7 .org 4 There’s a lot of IPC ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memory attach ● Pseudoterminals ● proc_vm_readv() / proc_vm_writev() ● Sockets ● Signals ● Stream vs Datagram (vs Seq. packet) ● Standard, Realtime ● UNIX vs Internet domain ● Eventfd ● POSIX message queues ● Futexes ● POSIX shared memory ● Record locks ● ● POSIX semaphores File locks ● ● Named, Unnamed Mutexes ● System V message queues ● Condition variables ● System V shared memory ● Barriers ● ● System V semaphores Read-write locks man7 .org 5 It helps to classify ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memory attach ● Pseudoterminals ● proc_vm_readv() / proc_vm_writev() ● Sockets ● Signals ● Stream vs Datagram (vs Seq. packet) ● Standard, Realtime ● UNIX vs Internet domain ● Eventfd ● POSIX message queues ● Futexes ● POSIX shared memory ● Record locks ● ● POSIX semaphores File locks ● ● Named, Unnamed Mutexes ● System V message queues ● Condition variables ● System V shared memory ● Barriers ● ● System V semaphores Read-write locks man7 .org 6 It helps to classify ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memoryn attach ● Pseudoterminals tio a ● proc_vm_readv() / proc_vm_writev() ● Sockets ic n ● Signals ● Stream vs Datagram (vs uSeq.
    [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]
  • IPC: Mmap and Pipes
    Interprocess Communication: Memory mapped files and pipes CS 241 April 4, 2014 University of Illinois 1 Shared Memory Private Private address OS address address space space space Shared Process A segment Process B Processes request the segment OS maintains the segment Processes can attach/detach the segment 2 Shared Memory Private Private Private address address space OS address address space space space Shared Process A segment Process B Can mark segment for deletion on last detach 3 Shared Memory example /* make the key: */ if ((key = ftok(”shmdemo.c", 'R')) == -1) { perror("ftok"); exit(1); } /* connect to (and possibly create) the segment: */ if ((shmid = shmget(key, SHM_SIZE, 0644 | IPC_CREAT)) == -1) { perror("shmget"); exit(1); } /* attach to the segment to get a pointer to it: */ data = shmat(shmid, (void *)0, 0); if (data == (char *)(-1)) { perror("shmat"); exit(1); } 4 Shared Memory example /* read or modify the segment, based on the command line: */ if (argc == 2) { printf("writing to segment: \"%s\"\n", argv[1]); strncpy(data, argv[1], SHM_SIZE); } else printf("segment contains: \"%s\"\n", data); /* detach from the segment: */ if (shmdt(data) == -1) { perror("shmdt"); exit(1); } return 0; } Run demo 5 Memory Mapped Files Memory-mapped file I/O • Map a disk block to a page in memory • Allows file I/O to be treated as routine memory access Use • File is initially read using demand paging ! i.e., loaded from disk to memory only at the moment it’s needed • When needed, a page-sized portion of the file is read from the file system
    [Show full text]
  • Interprocess Communication
    06 0430 CH05 5/22/01 10:22 AM Page 95 5 Interprocess Communication CHAPTER 3,“PROCESSES,” DISCUSSED THE CREATION OF PROCESSES and showed how one process can obtain the exit status of a child process.That’s the simplest form of communication between two processes, but it’s by no means the most powerful.The mechanisms of Chapter 3 don’t provide any way for the parent to communicate with the child except via command-line arguments and environment variables, nor any way for the child to communicate with the parent except via the child’s exit status. None of these mechanisms provides any means for communicating with the child process while it is actually running, nor do these mechanisms allow communication with a process outside the parent-child relationship. This chapter describes means for interprocess communication that circumvent these limitations.We will present various ways for communicating between parents and chil- dren, between “unrelated” processes, and even between processes on different machines. Interprocess communication (IPC) is the transfer of data among processes. For example, a Web browser may request a Web page from a Web server, which then sends HTML data.This transfer of data usually uses sockets in a telephone-like connection. In another example, you may want to print the filenames in a directory using a command such as ls | lpr.The shell creates an ls process and a separate lpr process, connecting 06 0430 CH05 5/22/01 10:22 AM Page 96 96 Chapter 5 Interprocess Communication the two with a pipe, represented by the “|” symbol.A pipe permits one-way commu- nication between two related processes.The ls process writes data into the pipe, and the lpr process reads data from the pipe.
    [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]
  • Interprocess Communications (Pipes)
    Multiple methods for Interprocess Communications Three examples: files, pipes, shared memory. In this figure, Local domain sockets would be conceptually similar to a named pipe. The second method refers to pipes Sources for these slides include: • W. Stevens, Unix Network Programming, Volumes 1 and 2 • M. Mitchell, J. Oldham, A. Samuel, Advanced Linux Programming 1 Interprocess Communication (IPC) ⚫ Linux supports the following IPC mechanisms: – Half duplex pipes – Full duplex pipes –only by using 2 pipes (other unix systems do support FD over a single pipe) – FIFOS (also called named pipes) – SYSV style message queues – SYSV style shared memory – Local Domain (UNIX Domain) sockets – Similar to a socket but modifications to the address/name aspect. (PF_LOCAL rather than PF_INET). – Sockets: Two processes can communicate using localhost. But it’s more efficient to use 2 pipes or local domain sockets. Pipe – used in a shell pipeline ⚫ Example of a pipeline - issue the following in a shell: – who | sort | wc 2 10 110 – The shell program creates three processes, two pipes are used as shown below. – The shell would use the dup2 call to duplicate the read end of each pipe to standard input and the write end to standard output. ⚫ int fd[2]; ⚫ pid_t pid; ⚫ pipe(fd); ⚫ pid = fork(); ⚫ If(pid == 0) { – dup2(fd[0], STDIN_FILENO); – exec(whatever); ⚫ } ⚫ The use of dup2 by a shell allows a program or filter to simply operate on data arriving through standard in….and sends output to standard out. It does not need to know the pipe descriptors involved…. 3 – Note – modified the pipeline- the figure assumes lp instead of wc .
    [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]