Linux进程间通信--进程,信号,管道,消息队列,信号量,共享内存 参考:<linux编程从入门到精通>,<Linux C程序设计大全>,<unix环境高级编程> 参考:C和指针学习 说明:本文非常的长,也是为了便于查找和比较,所以放在一起了 Linux 传统的进程间通信有很多,如各类管道.消息队列.内存共享.信号量等等.但它们都无法介于内核态与用户态使用,原因如表 通信方法 无法介于内核态与用户态的原因 管道(不包括命名管道) 局限于父子进程间的通信. 消息队列 在

我们已经知道,我们可以通过信号来终止进程,也可以通过信号来在进程间进行通信,程序也可以通过指定信号的关联处理函数来改变信号的默认处理方式,也可以屏蔽某些信号,使其不能传递给进程.那么我们应该如何设定我们需要处理的信号,我们不需要处理哪些信号等问题呢?信号集函数就是帮助我们解决这些问题的. 有关Linux进程间使用信号通信的更多内容,可以参阅我的另一篇文章,Linux进程间通信 -- 信号量函数 signal().sigaction() 下面是信号函数集: 1.int sigemptyset(si

sigpending函数返回信号集,其中的各个信号对于调用进程是阻塞的而不能递送,因而也一定是当前未决的.该信号集通过set参数返回.(这些信号是已经产生的信号,但因为信号屏蔽字中对其设置了屏蔽位,从而被阻塞,不能递送给进程的那些信号.注意sigpending返回的信号集与信号屏蔽字的区别.从集合角度来讲,此信号集是当前信号屏蔽字的子集.) #include <signal.h> int sigpending(sigset_t *set); 返回值:若成功则返回0,若出错则返回-   程序清单

sigprocmask,sigpending函数 分类: LINUX 2012-02-02 16:39 905人阅读 评论(0) 收藏 举报 signalredhatnulllinux [sigprocmask系统调用] 功能描述:设定对信号屏蔽集内的信号的处理方式(阻塞或不阻塞). 用法: #include <signal.h> int sigprocmask(int how, const sigset_t *set, sigset_t *oldset); 参数: how:用于指定信号修改的

信号的阻塞:通过sigprocmask()将信号集sigset_t中的信号设置为阻塞.SIG_BLOCK是指对相应信号的“递送阻塞”,内核在递送一个原来被阻塞的信号给进程时(而不是在产生该信号时),才决定对它的处理方式,那么进程在信号递送给它之前仍可改变对该信号的动作. 一个信号的"生命周期"为:产生(generation).未决(pending).递送(delivery) 如果将信号设置为阻塞,那么,在信号产生和递送之间的时间间隔内,称信号是未决的(pending). 如果信号被设置

信号源为目标进程产生了一个信号,然后由内核来决定是否要将该信号传递给目标进程.从信号产生到传递给目标进程的流程图如下图所示: 进程可以阻塞信号的传递.当信号源为目标进程产生了一个信号之后,内核会执行依次执行下面操作, 1. 如果目标进程设置了忽略该信号,则内核直接将该信号丢弃. 2. 如果目标进程没有阻塞该信号,则内核将该信号传递给目标进程,由目标进程执行相对应操作. 3. 如果目标进程设置阻塞该信号,则内核将该信号放到目标进程的阻塞信号列表中,等待目标进程对该类型信号的下一步设置.若目标进程后

sigset_t set sigemptyset(&set) :清空阻塞信号集合变量 sigfillset(&set) :添加所有的信号到阻塞集合变量里 sigaddset(&set,SIGINT):添加单一信号到阻塞信号集合变量 sigdelset(&set,SIGINT):从阻塞信号集合变量中删除单一信号 void handler(int sig)    //信号处理函数的实现 { printf("SIGINT sig"); } 功能:返回在阻塞期间

转自 http://blog.csdn.net/elbort/article/details/7594772 sigprocmask函数:功能描述:设定对信号屏蔽集内的信号的处理方式(阻塞或不阻塞).用法:#include <signal.h>int sigprocmask(int how, const sigset_t *set, sigset_t *oldset);NOTE: If oldset is non-null, the previous value of the signal m

某招聘要求:熟悉高性能分布式网络服务端设计开发,熟悉epoll.多线程.异步IO.事件驱动等服务端技术: <UNIX环境高级编程(第3版)>apue.h等源码文件的编译安装 <UNIX网络编程(第3版)>unp.h等源码文件的编译安装 编译基础 C/C++的开发环境安装 .编译器 cc.gcc.g++.CC 的区别 [荐]C/C++开发工具gcc/gdb .make 和 makefile 的关系 利用 autoconf 和 automake 生成 Makefile 文件 C/C++

string 字符串操作 操作数的都是 ( char * )型,操作数必须是指向字符串的指针("a"),不能是字符('a'),操作时不考虑末尾的'\0'. size_t strlen( const char *s ); 字符串求长,返回字符串或指针的实际大小,和 sizeof() 不同,比如创建字符数组 strlen 只返回其中字符串的大小,不包括 '\0' char *strrev( char *s ); 字符串反转,不包括 NULL char *strcpy( char *dest

前言 在windows 下 系统核心态程序蓝屏,会产生dump文件. 用户级程序在设置后,程序崩溃也会产生dump文件.以方便开发者用windbg进行分析. so,linux 系统也有一套这样的东东----->Linux Core Dump Linux Core Dump 引用 文章 <Linux Core Dump>  http://www.cnblogs.com/hazir/p/linxu_core_dump.html 的话: 当程序运行的过程中异常终止或崩溃,操作系统会将程序当时的

1.增加 Menu 内核命令行 调试系统调用. 步骤:删除menu git clone        (tab) make rootfs 这就是我们将 fork 函数写入 Menu 系统内核后的效果,通过命令行,实现了操作系统调用过程. 2.GDB 追踪内核调用 sys_fork 通过查询操作系统内核调用函数 API,我们知道 fork 函数的系统调用是 sys_fork,下面我们就通过 GDB 来追踪 sys_fork 的调用过程. 由图可知,sys_fork 在底层调用的是 do_fork

首先谢谢 @小尧弟 这位朋友对我昨天夜里写的一篇<浅谈Linux中的信号处理机制(一)>的指正,之前的题目我用的“浅析”一词,给人一种要剖析内核的感觉.本人自知功力不够,尚且不能对着Linux内核源码评头论足.以后的路还很长,我还是一步一个脚印的慢慢走着吧,Linux内核这座山,我才刚刚抵达山脚下. 好了,言归正传,我接着昨天写下去.如有错误还请各位看官指正,先此谢过. 上篇末尾,我们看到了这样的现象:send进程总共发送了500次SIGINT信号给rcv进程,但是实际过程中rcv只接受/处理

本文列出了大部分常见的Linux系统调用,并附有简要中文说明. 以下是Linux系统调用的一个列表,包含了大部分常用系统调用和由系统调用派生出的的函数.这可能是你在互联网上所能看到的唯一一篇中文注释的Linux系统调用列表,即使是简单的字母序英文列表,能做到这么完全也是很罕见的. 按照惯例,这个列表以man pages第2节,即系统调用节为蓝本.按照笔者的理解,对其作了大致的分类,同时也作了一些小小的修改,删去了几个仅供内核使用,不允许用户调用的系统调用,对个别本人稍觉不妥的地方作了一些小的修改

在Linux中每一个进程的数据是存储在一个task_struct结构(定义在sched.h中)中的. struct task_struct { volatile long state; /* -1 unrunnable, 0 runnable, >0 stopped */ struct thread_info *thread_info; atomic_t usage; unsigned long flags; /* per process flags, defined below */ unsi

张雨梅   原创作品转载请注明出处 <Linux内核分析>MOOC课程http://mooc.study.163.com/course/USTC-10000 1.给menuos添加命令 改写menu下的test.c,在main中添加两行, MenuConfig("getuid","show system uid",Getuid);    MenuConfig("getuidasm","show system uidasm&q

一   使用gdb工具跟踪分析一个自添加的系统调用 应用程序的进程通常在用户空间下运行,当它调用一个系统调用时,进程进入内核空间,执行的是kernel内部的代码,从而具有执行特权指令的权限,完成特定的功能. 在上次实验的基础上修改test.c,添加自己实现的setuid系统调用,部分代码修改如下: int uid_c() { int i=65535,k=0; i=getuid(); printf("current user id is:%d\n",i); setuid(200); k=

本文所有的分析内容都是基于Linux3.18.6内核,鉴于对应不同内核版本,系统调用的实现不相同.若需要分析其他版本内核的系统调用的实现过程,请谨慎参考. system_call函数的功能是用来响应外壳函数发起的0x80中断,当外壳函数通过,其位于arch/x86/kernel/entry_32.S文件内.具体的执行流程,上一篇分析已列出,不再赘述.程序片段如下所示: ENTRY(system_call) RING0_INT_FRAME # can't unwind into user spac

1.可重入锁 如果锁具备可重入性,则称作为可重入锁. ========================================== (转)可重入和不可重入 2011-10-04 21:38 这种情况出现在多任务系统当中,在任务执行期间捕捉到信号并对其进行处理时,进程正在执行的指令序列就被信号处理程序临时中断.如果从信号处理程序返回,则继续执行进程断点处的正常指令序列,从重新恢复到断点重新执行的过程中,函数所依赖的环境没有发生改变,就说这个函数是可重入的,反之就是不可重入的.众所周知,在进

[a] 常用信号 SIGABRT 调用 abort 函数时产生此信号,进程异常终止 SIGALRM 调用 alarm 或 setitimer 函数超时之后产生 SIGCHLD 子进程终止或 stop 时内核向父进程发送此信号 SIGFPE 算术异常,如除以 0 或浮点溢出等 SIGHUP 终端连接断开时,会话首进程将收到此信号:向守护进程发送此信号使之重新读取其配置文件 SIGINT 中断信号,通常由 Ctrl + C 键发出,发送至前端进程组的所有进程 SIGQUIT 退出信号,通常由 Ctr

信号本质上就是一个软件中断,它既可以作为两个进程间的通信的方式, 更重要的是, 信号可以终止一个正常程序的执行, 通常被用于处理意外情况 ,* 信号是异步的, 也就是进程并不知道信号何时会到达 $kill -9 3390 #向PID为3390的进程发送编号为9的信号=>一个两个进程间通信的方式之一 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SI