1 / 15

CSC 552.201 - Advanced Unix Programming, Fall, 2008

CSC 552.201 - Advanced Unix Programming, Fall, 2008. Welcome back to UNIX System Programming! Monday, September 22, class 5. sigaction() and signal() and kill().

ludlow
Download Presentation

CSC 552.201 - Advanced Unix Programming, Fall, 2008

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CSC 552.201 - Advanced Unix Programming, Fall, 2008 Welcome back to UNIX System Programming! Monday, September 22, class 5

  2. sigaction() and signal() and kill() • A UNIX signal is like a user-process-level interrupt. Each distinct signal provides a way to trigger asynchronous processing in a single-threaded (or multi-threaded) process. • sigaction() system call specifies a handler • signal() was the old way of doing that • kill() system call sends a signal to another process

  3. sigaction() #include <signal.h> int sigaction(int sig, const struct sigaction *restrict act, struct sigaction *restrict oact); The sigaction() function allows the calling process to examine or specify the action to be taken on delivery of a specific signal. See signal.h(3HEAD) for an explanation of general signal concepts. The sigaction structure includes the following members: void (*sa_handler)(int); // SIG_DFL, SIG_IGN or event-handling function void (*sa_sigaction)(int, siginfo_t *, void *); // realtime handler sigset_t sa_mask; // other signals to be blocked during execution int sa_flags; //flags and options

  4. signal.h • Signals / default actions are on p. 257 of text SIGHUP 1 Exit Hangup (see termio(7I)) SIGINT 2 Exit Interrupt (see termio(7I)) SIGQUIT 3 Core Quit (see termio(7I)) SIGILL 4 Core Illegal Instruction SIGTRAP 5 Core Trace or Breakpoint Trap SIGABRT 6 Core Abort SIGEMT 7 Core Emulation Trap SIGFPE 8 Core Arithmetic Exception • SIGKILL 9 Exit Killed SIGBUS 10 Core Bus Error SIGSEGV 11 Core Segmentation Fault SIGSYS 12 Core Bad System Call SIGPIPE 13 Exit Broken Pipe SIGALRM 14 Exit Alarm Clock SIGTERM 15 Exit Terminated SIGUSR1 16 Exit User Signal 1 SIGUSR2 17 Exit User Signal 2 SIGCHLD 18 Ignore Child Status Changed SIGPWR 19 Ignore Power Fail or Restart SIGWINCH 20 Ignore Window Size Change SIGURG 21 Ignore Urgent Socket Condition SIGPOLL 22 Exit Pollable Event (see streamio(7I)) SIGSTOP 23 Stop Stopped (signal) SIGTSTP 24 Stop Stopped (user) (see termio(7I)) SIGCONT 25 Ignore Continued SIGTTIN 26 Stop Stopped (tty input) (see termio(7I)) SIGTTOU 27 Stop Stopped (tty output) (see termio(7I)) SIGVTALRM 28 Exit Virtual Timer Expired SIGPROF 29 Exit Profiling Timer Expired SIGXCPU 30 Core CPU time limit exceeded (see getrlimit(2)) SIGXFSZ 31 Core File size limit exceeded (see getrlimit(2)) Some abort the process, some core dump by default.

  5. kill() • kill() send a signal to a process #include <sys/types.h> #include <signal.h> int kill(pid_t pid, int sig); pid from getpid(), getppid(), fork() You could pass them via pipes or FIFOs. kill also available as level 1 shell /usr/bin/kill unsigned alarm(unsigned secs) schedules SIGALRM

  6. signal masks • signal masks disable target signals until a masked signal is re-enabled • unlike SIG_IGN, the ignore+discard handler • sigset_t objects can be set up for signals, similar to setting up fd_sets for select()/poll() • int sigprocmask(…) sets up signal masks at the process level • pthread_sigmask for multi-threaded processes

  7. pause() • int pause(void) pauses until interruption by a signal • always returns -1 • pause() suffers from a race condition – between a call to sigprocmask() and pause(), the signal may already have arrived and been handled • signal unmasking and pausing should be atomic

  8. sigsuspend and sigwait • int sigsuspend(const sigset_t *set); • set is set of masked (disabled) signals • former set is restored on return after a non-terminating signal • int sigwait(const sigset_t *set, int *sig); • synchronously wait on a set of signals in the set • this set is independent of the process mask (and thread masks) • disable those signals in the process (and thread) masks via sigprocmask() in order to avoid “competition”

  9. race conditions • Most 3C library functions and many system calls are not safe to use in a signal handler because its asynchronous execution may occur within a critical section! • Text p. 285 holds a list of safe POSIX functions. • Perform minimal flag setting within signal handlers. Do not block indefinitely! • Do not use sigsetjmp, siglongjmp, setjmp, longjmp – they leak storage from the stack!

  10. Asynchronous I/O and signals • aio_read() and aio_write() use signals to generate events on I/O completion. • Doing substantial data processing inside a signal handler is extremely error prone! • Create a worker thread that is allowed to block, and let it blocks using select(), read() and write(). • It can use semaphores, etc. to sync with other threads. Signal handlers cannot!

  11. Assignment: Spy on GNU chess! • Your initial assignment is to write an interceptor that sits between xboard and gnuchess and logs interactions while you play chess. Use your trace log plus source code and docs to understand the xboard <-> gnuchess command and results protocol. • xboard <-> interceptor <-> gnuchess xboard • stdin log, stdout log, stderr log for gnuchess

  12. The bigger assignment: Sound • Install ChucK on a machine with some speakers. http://chuck.cs.princeton.edu/ • My chess program, linked to my web page, as a ChucK directory, with a README. • Open Sound Control (OSC) over UDP datagrams  a ChucK process running my sound generator  speakers • But, Professor Parson, where do the OSC/UDP datagrams comes from?

  13. A Python chess-to-music game • One or more Python game GUIs  Python game server that takes commands from command line (stdin / stdout), and also accepts GUI commands from UDP datagrams. • This Python program generates OSC/UDP  ChucK. • The command line server, like gnuchess, is a stdin / stdout / stderr process.

  14. Project goals • Allow Python chess-to-music program to play a human against the machine (gnuchess). • Support alternative, networked GUI (in Python) for gnuchess. • Have some fun while learning fork, exec, file IO, sockets, networking and multithreading. • Live long and prosper.

  15. Summary • Ultimately you are creating a game framework to integrate two or more running games. • An ideal goal would be to allow support for different protocols using a plugin parser. • The immediate goal is to intercept, redirect, etc. commands passing between xboard <-> gnuchess, and also my Python game server <-> Python GUI, and to translate between them.

More Related