精华内容
参与话题
问答
  • 关于errno = EINTR的小结

    千次阅读 2015-12-30 09:44:27
    如果read()读到数据为0,那么就表示文件读完了,如果在读的过程中遇到了中断则read()应该返回-1,同时置errno为EINTR。   因此判断read的条件如下: if { if==0 { 表示文件结束, 处理  } if...

      如果read()读到数据为0,那么就表示文件读完了,如果在读的过程中遇到了中断则read()应该返回-1,同时置errno为EINTR。
     
    因此判断read的条件如下:

    if <=0
     {
          if==0
          {
    
              表示文件结束, 处理
      }
          if(<0 && errno==EINTR)
          {
    
          表示中断,处理
    
        }
    
          else
    
         {
            否则,出错
         }
    
    }

         如果 write()返回0,那么就表示出错,也就是无法写入了;而如果在写的过程中遇到了中断,那么write()会返回-1,同时置errno为EINTR。

    因此判断write的条件如下: 

    if<=0
     {
         if<0
         {
            if errno==EINTR  
              那么重试
     
           else
               错误处理
         }
     
        if ==0
            break;
     }

    ssize_t   readn ( int fd, void *vptr, size_t n )
     {
         size_t     nleft;
         ssize_t   nread;
         char       *ptr;
     
        ptr=vptr;
         nleft=n;
     
        while ( nleft>0 )
         {
            if ( ( nread = read ( fd,ptr,nleft ) ) < 0 )
            {
               if ( errno == EINTR )
                  nread = 0;
               else
                  return ( -1 );
            }else if(nread = =0)
    
             break;
    
           nleft-=nread;
            ptr+=nread;
         }return ( n-nleft );
    
     }
     
    ssize_t   writen (  int fd,   const void *ptr,    size_t n  )
     {
         size_t   nleft;
         ssize_t   nwritten;
         const char *ptr;
     
        ptr=vptr;
         nleft=n;
     
        while ( nleft>0 )
         {
            if( ( nwritten=write( fd, ptr, nleft ) )<=0 )
            {
               if( nwritten<0 && errno == EINTR )
                  nwritten = 0;
               else
                  return (-1);
            }
    
               
              nleft-=nwritten;
               ptr+=nwritten;
         }
     
        return (n);
     }

     

    写函数write
     ssize_t write(int fd,const void *buf,size_t nbytes)
     write函数将buf中的nbytes字节内容写入文件描述符fd。成功时返回写的字节数,失败时返回-1,并设置errno变量。
     在网络程序中,当我们向套接字文件描述符写时有俩种可能:
     1) write的返回值大于0,表示写了部分或者是全部的数据;
     2) 返回的值小于0,此时出现了错误,我们要根据错误类型来处理。
     如果错误为EINTR表示在写的时候出现了中断错误。如果为EPIPE表示网络连接出现了问题(对方已经关闭了连接)。
     读函数read
       ssize_t read(int fd,void *buf,size_t nbyte)
       read函数是负责从fd中读取内容。当读成功时,read返回实际所读的字节数。如果返回的值是0,表示已经读到文件的结束了。小于0表示出现了错误。如果错误为EINTR说明读是由中断引起的,如果是ECONNREST表示网络连接出了问题。

    展开全文
  • 中断产生EINTR错误

    千次阅读 2018-05-22 11:53:57
    https://blog.csdn.net/u011068702/article/details/620697141、介绍慢系统调用该术语适用于那些可能永远阻塞的系统调用。永远阻塞的系统调用是指调用永远无法返回,多数网络支持函数都属于这一类。...

    https://blog.csdn.net/u011068702/article/details/62069714

    1、介绍慢系统调用

    该术语适用于那些可能永远阻塞的系统调用。永远阻塞的系统调用是指调用永远无法返回,多数网络支持函数都属于这一类。如:若没有客户连接到服务器上,那么服务器的accept调用就会一直阻塞。

    慢系统调用可以被永久阻塞,包括以下几个类别:

    (1)读写‘慢’设备(包括pipe,终端设备,网络连接等)。读时,数据不存在,需要等待;写时,缓冲区满或其他原因,需要等待。读写磁盘文件一般不会阻塞。
    (2)当打开某些特殊文件时,需要等待某些条件,才能打开。例如:打开中断设备时,需要等到连接设备的modem响应才能完成。
    (3)pause和wait函数。pause函数使调用进程睡眠,直到捕获到一个信号。wait等待子进程终止。
    (4)某些ioctl操作。
    (5)某些IPC操作。



    2、EINTR错误产生的原因

    如果进程在一个慢系统调用(slow system call)中阻塞时,当捕获到某个信号且相应信号处理函数返回时,这个系统调用被中断,调用返回错误,设置errno为EINTR(相应的错误描述为“Interrupted system call”)。

    如下表所示的系统调用就会产生EINTR错误,当然不同的函数意义也不同。


    系统调用函数
        
    errno为EINTR表征的意义

    [html] view plain copy
    1. write  
    2. 由于信号中断,没写成功任何数据。  
    3.   
    4. The call was interrupted by a signal before any data was written.  
    5. open  
    6.       
    7. 由于信号中断,没读到任何数据。  
    8. The call was interrupted by a signal before any data was read.  
    9. recv  
    10.       
    11. 由于信号中断返回,没有任何数据可用。  
    12. The receive was interrupted by delivery of a signal before any data were available.  
    13. sem_wait  
    14.       
    15. 函数调用被信号处理函数中断。  
    16. The call was interrupted by a signal handler.  


    3、解决办法

    既然系统调用会被中断,那么别忘了要处理被中断的系统调用。有三种处理方式:


    1 人为重启被中断的系统调用


    当碰到EINTR错误的时候,有一些可以重启的系统调用要进行重启,而对于有一些系统调用是不能够重启的。例如:accept、read、write、select、和open之类的函数来说,是可以进行重启的。不过对于套接字编程中的connect函数我们是不能重启的,若connect函数返回一个EINTR错误的时候,我们不能再次调用它,否则将立即返回一个错误。针对connect不能重启的处理方法是,必须调用select来等待连接完成。

    理解“重启”?

    一些IO系统调用执行时,如 read 等待输入期间,如果收到一个信号,系统将中断read, 转而执行信号处理函数. 当信号处理返回后, 系统遇到了一个问题: 是重新开始这个系统调用, 还是让系统调用失败?早期UNIX系统的做法是, 中断系统调用,并让系统调用失败, 比如read返回 -1, 同时设置 errno 为EINTR中断了的系统调用是没有完成的调用,它的失败是临时性的,如果再次调用则可能成功,这并不是真正的失败,所以要对这种情况进行处理, 典型的方式为如下,我们采用accept函数为例子,代码如下


    [html] view plain copy
    1. ACCEPT:  
    2.     clifd = accept(srvfd,(struct sockaddr*)&cliaddr,&cliaddrlen);  
    3.   
    4.     if (clifd == -1) {  
    5.         if (errno == EINTR) {  
    6.             goto ACCEPT;  
    7.         } else {  
    8.             fprintf(stderr, "accept fail,error:%s\n", strerror(errno));  
    9.             return -1;  
    10.         }  
    11.     }  



    2 安装信号时设置 SA_RESTART属性(该方法对有的系统调用无效)

    [html] view plain copy
    1. struct sigaction action;    
    2.      
    3. action.sa_handler = handler_func;    
    4. sigemptyset(&action.sa_mask);    
    5. action.sa_flags = 0;    
    6. /* 设置SA_RESTART属性 */    
    7. action.sa_flags |= SA_RESTART;    
    8.      
    9. sigaction(SIGALRM, &action, NULL);    

    并不是所有的都有效



    3  忽略信号(让系统不产生信号中断)

    [html] view plain copy
    1. struct sigaction action;    
    2.      
    3. action.sa_handler = SIG_IGN;    
    4. sigemptyset(&action.sa_mask);    
    5.      
    6. sigaction(SIGALRM, &action, NULL);    

    所以建议大家用第一种方法,重启。
    展开全文
  • Linux errno详解。... ---------------------------------------------------------------------------------------------------------- 慢系统调用(slow system call...

    Linux errno详解。https://blog.csdn.net/tantion/article/details/86520806

    ----------------------------------------------------------------------------------------------------------

    慢系统调用(slow system call):此术语适用于那些可能永远阻塞的系统调用。永远阻塞的系统调用是指调用有可能永远无法返回,多数网络支持函数都属于这一类。如:若没有客户连接到服务器上,那么服务器的accept调用就没有返回的保证。

    EINTR错误的产生:当阻塞于某个慢系统调用的一个进程捕获某个信号且相应信号处理函数返回时,该系统调用可能返回一个EINTR错误。例如:在socket服务器端,设置了信号捕获机制,有子进程,当在父进程阻塞于慢系统调用时由父进程捕获到了一个有效信号时,内核会致使accept返回一个EINTR错误(被中断的系统调用)。

    当碰到EINTR错误的时候,可以采取有一些可以重启的系统调用要进行重启,而对于有一些系统调用是不能够重启的。例如:accept、read、write、select、和open之类的函数来说,是可以进行重启的。不过对于套接字编程中的connect函数我们是不能重启的,若connect函数返回一个EINTR错误的时候,我们不能再次调用它,否则将立即返回一个错误。针对connect不能重启的处理方法是,必须调用select来等待连接完成。

     

    在 linux 或者 unix 环境中, errno 是一个十分重要的部分。在调用的函 数出现问题的时候,我们可以通过 errno 的值来确定出错的原因,这就会 涉及到一个问题,那就是如何保证 errno 在多线程或者进程中安全?我们希望在多线程或者进程中,每个线程或者进程都拥有自己独立和唯一的一个 errno ,这样就能够保证不会有竞争条 件的出现。一般而言,编译器会自动保证 errno 的安全性,但是为了妥善期间,我们希望在写 makefile 的时 候把 _LIBC_REENTRANT 宏定义,比 如我们在检查 <bits/errno.h> 文件中发现如下的定义: 


    C代码 
    # ifndef __ASSEMBLER__ 
    /* Function to get address of global `errno' variable. */ 
    extern int *__errno_location (void) __THROW __attribute__ ((__const__)); 

    # if !defined _LIBC || defined _LIBC_REENTRANT 
    /* When using threads, errno is a per-thread value. */ 
    # define errno (*__errno_location ()) 
    # endif 
    # endif /* !__ASSEMBLER__ */ 
    #endif /* _ERRNO_H */ 



    也就是说,在没有定义 __LIBC 或者定义 _LIBC_REENTRANT 的时候, errno 是多线程 / 进程安全的。 
    一般而言, __ASSEMBLER__, _LIBC 和 _LIBC_REENTRANT 都不会被编译器定义,但是如果我们定义 _LIBC_REENTRANT 一次又何妨那? 
    为了检测一下你编译器是否定义上述变量,不妨使用下面一个简单程序。 


    C代码 
    #include <stdio.h> 
    #include <errno.h> 

    int main( void ) 

    #ifndef __ASSEMBLER__ 
    printf( "Undefine __ASSEMBLER__\n" ); 
    #else 
    printf( "define __ASSEMBLER__\n" ); 
    #endif 

    #ifndef __LIBC 
    printf( "Undefine __LIBC\n" ); 
    #else 
    printf( "define __LIBC\n" ); 
    #endif 

    #ifndef _LIBC_REENTRANT 
    printf( "Undefine _LIBC_REENTRANT\n" ); 
    #else 
    printf( "define _LIBC_REENTRANT\n" ); 
    #endif 

    return 0; 




    希望读者在进行移植的时候,读一下相关的 unix 版本的 <bits/errno.h> 文 件,来确定应该定义什么宏。不同的 unix 版本可能存在着一些小的差别!

     

    有时候,在调用系统调用时,可能会接收到某个信号而导致调用退出。譬如使用system调用某个命令之后该进程会接收到SIGCHILD信号,然后如果这个进程的线程中有慢系统调用,那么接收到该信号的时候可能就会退出,返回EINTR错误码。

    EINTR
      linux中函数的返回状态,在不同的函数中意义不同:

    1)write
      表示:由于信号中断,没写成功任何数据。
      The call was interrupted by a signal before any data was written.

    2)read
      表示:由于信号中断,没读到任何数据。
      The call was interrupted by a signal before any data was read.

    3)sem_wait
      函数调用被信号处理函数中断
      The call was interrupted by a signal handler.

    4)recv
      由于信号中断返回,没有任何数据可用。
      function was interrupted by a signal that was caught, before any data was available.

     

    调用系统调用的时候,有时系统调用会被中断.此时,系统调用会返回-1,并且错误码被置为EINTR.但是,有时并不将这样的情况作为错误.有两种处理方法:

    1.如果错误码为EINTR则重新调用系统调用,例如Postgresql中有一段代码:


    view plain
    copy to clipboard
    print
    ?
    retry1: 
    if (send(port->sock, &SSLok, 1, 0) != 1) 

    if (errno == EINTR) 
    goto retry1; /* if interrupted, just retry */ 

    [cpp] view plain
    copy

    retry1: 
    if (send(port->sock, &SSLok, 1, 0) != 1) 

    if (errno == EINTR) 
    goto retry1; /* if interrupted, just retry */ 




    2.重新定义系统调用,忽略错误码为EINTR的情况.例如,Cherokee中的一段代码:


    view plain
    copy to clipboard
    print
    ?
    int 
    cherokee_stat (const char *restrict path, struct stat *buf) 

    int re; 
    do { 
    re = stat (path, buf); 
    } while ((re == -1) && (errno == EINTR)); 
    return re; 






    最近 socket 读数据老是遇到 Interrupted system call (EINTR),代码改为如下解决


    while (1)

    {
    select(socket+1, &readfds, NULL, NULL, &tv);
    if (FD_ISSET(socket, &readfds))

    {
    printf("connection got!\n");

    break;

    }
    else{
    if (errno == EINTR)
    continue;
    else
    printf("Timed out.\n");
    }
    }


    下面的列表显示常见的 Linux 系统错误代码。 
    1 EPERM
    Operation not permitted
    操作不许可 
    2 ENOENT
    No such file or directory
    无此文件或目录 
    3 ESRCH
    No such process
    无此过程 
    4 EINTR 
    Interrupted system call
    系统调用被禁止 
    5 EIO 
    I/O error
    I/O 错误 
    6 ENXIO 
    No such device or address
    无此器件或地址 
    7 E2BIG 
    Arg list too long
    Arg 列表太长 
    8 ENOEXEC 
    Exec format error
    Exec 格式错误 
    9 EBADF 
    Bad file number
    文件数目错误
    10 ECHILD
    No child processes
    无子过程
    11 EAGAIN
    Try again
    再试一遍
    12 ENOMEM
    Out of memory 
    内存溢出
    13 EACCES
    Permission denied 
    许可拒绝
    14 EFAULT
    Bad address 
    错误的地址
    15 ENOTBLK
    Block device required 
    需要块设备
    16 EBUSY
    Device or resource busy 
    设备或资源忙
    17 EEXIST
    File exists 
    文件存在
    18 EXDEV
    Cross-device link 
    跨器链接
    19 ENODEV
    No such device 
    无此设备
    20 ENOTDIR
    Not a directory 
    不是一个目录
    21 EISDIR
    Is a directory 
    是一个目录
    22 EINVAL
    Invalid argument 
    无效的函数自变量
    23 ENFILE
    File table overflow 
    文件表溢出
    24 EMFILE
    Too many open files
    打开的文件太多
    25 ENOTTY
    Inappropriate ioctl for device 

    26 ETXTBSY
    Text file busy 
    文本文件忙
    27 EFBIG
    File too large
    文件太大
    28 ENOSPC
    No space left on device 
    磁盘空间不足
    29 ESPIPE 
    Illegal seek 
    不合法的寻找
    30 EROFS 
    Read-only file system 
    只读文件系统
    31 EMLINK 
    Too many links
    太多的链接

    展开全文
  • 最近在工作中遇到了EINTR错误,感到比较困惑,几番研究之后,颇有心得和收获,特记录如下,便于以后查询,也给有同样困惑的朋友们提供一点借鉴。 我们经常在网络编程中会看到这样,当执行一个可能会阻塞的系统调用...

    转自:http://www.xuebuyuan.com/1470645.html

    最近在工作中遇到了EINTR错误,感到比较困惑,几番研究之后,颇有心得和收获,特记录如下,便于以后查询,也给有同样困惑的朋友们提供一点借鉴。

            我们经常在网络编程中会看到这样,当执行一个可能会阻塞的系统调用后,在返回的时候需要检查下错误码(if errno == EINTR),如果是这样的错误,那我们一般会重新执行该系统调用。所以经常的写法是:

    repeat:

    if(read(fd, buff, size) < 0)

    {

            if(errno == EINTR)

                    goto repeat;

          else

                   printf("read failed");

    }

    但一般我们在读/写磁盘文件的时候却不太会判断这个错误,那我们到底什么时候该判断而什么时候又不要去判断呢?这是个问题。针对这个问题我特意做了一些测试。首先是读磁盘文件,测试代码如下:

    #define _GNU_SOURCE
    
    #include <stdio.h>
    #include <unistd.h>
    #include <stdlib.h>
    #include <fcntl.h>
    #include <signal.h>
    #include <string.h>
    #include <errno.h>
    
    #include <sys/types.h>
    #include <sys/stat.h>
    
    void hup_handler(int sig)
    {
            printf(".");
            fflush(stdout);
    }
    
    int main()
    {
            int i = 0;
            struct sigaction act;
            const int buffSize = 1 << 27; 
            int allocated = 0;
            char* buf = NULL;
    
            act.sa_handler = hup_handler;
            act.sa_flags = SA_INTERRUPT;
            sigemptyset(&act.sa_mask);
            allocated = posix_memalign((void**)&buf, getpagesize(), buffSize);
            if (0 != allocated)
            {
                perror("posix_memalign error");
                exit(1);
            }
    
            sigaction(SIGHUP, &act, NULL);
            int fd = open("testfile", O_RDWR | O_DIRECT);
            //for (i = 0; i < 1; ++i)
            for (; 

    ;)

     
            {
                if (lseek(fd, 0, SEEK_SET) == -1)
                {
                    printf("lseek failed: %s\n", strerror(errno));
                }
                if (read(fd, buf, buffSize) != buffSize)
                {
                    printf("read failed: %s\n", strerror(errno));
                }
            }
    }

    代码中注册了信号SIG_HUP的信号处理函数,收到信号的时候应该会进入该处理函数。使用了O_DIRECT方式直接从磁盘读,然后运行该程序。在另外一个终端发送信号

    while true; do pkill -HUP read; done

    观察read进程,发现read确实进入了信号处理函数(终端输出了"......")但是,程序并没有打印出“read failed”错误,这与我们的预期不太符合,测试发现调用write接口时,现象也一样。

    为了进一步验证,我尝试去read终端设备,然后发信号,整个流程跟上面read测试基本相同,测试代码如下:

    #include <stdio.h>
    #include <stdlib.h>
    #include <sys/types.h>
    #include <string.h>
    #include <errno.h>
    #include <unistd.h>
    #include <signal.h>
    #include <stdbool.h>
    
    
    
    
    void int_handler(int signum)
    {
        printf("....\n");
    }
    
    
    
    int main()
    {
        char buf[128];
        ssize_t ret;
        struct sigaction oldact;
        struct sigaction act;
    
        act.sa_handler = int_handler;
        //act.sa_flags = SA_INTERRUPT;
        act.sa_flags = SA_RESTART;
        sigemptyset(&act.sa_mask);
    
        if(-1 == sigaction(SIGHUP, &act, &oldact))
        {
            exit(1);
        }
    
        bzero(buf, 100);
    
        while(true)
        {
            ret = read(STDIN_FILENO, buf, 10);
            if(-1 == ret) 
            {
                perror("read terminal");
                //printf("read error%s\n"), strerror(errno);
            }
        }
           
        return 0;
    }

    编译运行该函数,然后在另外一个终端为其发送信号:

    while true; do pkill -HUP read; done

    然后观察发现,第一终端处理函数确实被执行了,然后read函数不断打印错误,“read terminal:Interuptible system call”。发现read函数确实在执行成功以前被信号中断了,返回EINTR错误。
    这种情况在read socket也同样出现。那为什么read磁盘文件不会出现上面的情况呢?
    为了理解各种原因,我们首先来看看linux的信号处理流程。
    一般来说,信号处理函数会在进程执行系统或者库函数调用退出时刻被执行,也就是说,进程的信号处理是在系统调用从内核态返回至用户态之前被执行的,如果该进程收到了信号的话。对于一直处于RUNNING态的进程来说,会在系统调用执行完成后,返回用户态前夕执行信号处理函数。
    但是,如果进程在内核态进行了状态转换,这时候处理流程就有点微妙的变化了。如由于等待某些事件的发生(最典型的IO等待),进程可能会从RUNNING状态转变为休眠状态,休眠状态的进程会被切换出CPU。但休眠状态有两种:第一是INTERUPTIBLE进程,第二种UNINTERUPTIBLE进程。第一种进程是可被信号唤醒的进程,第二种是不可被信号唤醒的进程,这就是问题的关键。对于INTERUPTIBLE状态的进程,一旦被信号唤醒后,会退出内核态执行,退出内核态之前执行信号处理函数。如果资源没准备好,那此时可能会设置错误码为EINTR。但是对于处于UNTERUPTIBLE状态的进程,该进程是不可被信号唤醒的,也就是说,当进程休眠时,会屏蔽所有的信号,直到它从休眠状态返回至RUNNING状态,执行完成后,返回上次执行的地方继续运行,然后退出内核态时候执行所有信号的处理函数。也就是说,这个状态的进程应该是不会被信号中断的,只会等到资源准备妥当时候才会被唤醒,这时候应该不存在会返回EINTR错误的情况。
    为了验证这种情况,我们使用ps -aux查看了上述几种情况下进程所处的状态。首先是读磁盘,ps-aux发现其显示状态为D(即UNTERUPTIBLE),接下来读terminal,ps -aux显示其状态为S(INTERUPTIBLE)。
    这就能解释上述两种情况显示的现象不一致的原因了。read磁盘的时候进程是处于UNINTERUPTIBLE状态,没法被信号唤醒,只能等到read到的数据准备好的时候被唤醒,这个时候再从内核态返回至用户态处理信号处理函数时,并不会出现EINTR错误。
    而对于read读终端,情况则不一样,它处于INTERUPTIBLE状态,当被信号唤醒时,会直接退出内核态,此时应该提醒用户态资源并没有准备好,因此应该返回EINTR错误。以便用户态可以做出自己的决定。
    备注:如果不想内核在系统调用返回EINTR错误,那么可以将信号处理函数的标记位设置SA_RESTART。




    本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/sky-heaven/p/7115198.html,如需转载请自行联系原作者

    展开全文
  • EINTR

    2020-04-27 17:48:25
    慢系统调用 ...EINTR 调用系统调用被中断,返回错误码EINTR 触发例子,永远阻塞的系统调用进程,接收到信号,执行注册的信号回调函数,慢系统调用被中断,触发EINTR 处理 重复系统调用 忽略错误 ...
  • EINTR error

    万次阅读 2013-09-14 22:58:05
    总结:本问介绍了EINTR错误产生的原因,以及如何解决,并在最后给出一个实例,通过该实例可以解决调用ioctl产生的EINTR错误。
  • EINTR

    2012-05-10 19:23:44
    EINTR 便于记忆,可理解为 ERROR INTTERUPT 的缩写
  • EINTR错误

    万次阅读 2012-02-22 17:56:19
    慢系统调用(slow system call):此术语适用于那些可能永远阻塞的系统...EINTR错误的产生:当阻塞于某个慢系统调用的一个进程捕获某个信号且相应信号处理函数返回时,该系统调用可能返回一个EINTR错误。例如:在socket服
  • linux中对errno是EINTR的处理

    万次阅读 2016-05-18 15:53:24
    慢系统调用(slow system call):此术语适用于那些可能永远阻塞的系统...EINTR错误的产生:当阻塞于某个慢系统调用的一个进程捕获某个信号且相应信号处理函数返回时,该系统调用可能返回一个EINTR错误。例如:在socke
  • EINTR

    2020-06-30 17:38:52
    并且我们为该信号设置了信号处理函数,在信号处理函数返回后,程序将面临继续执行或不执行慢速系统调用两种选择,默认情况下是系统调用将被中断,并且errno被设置为EINTR。我们可以选择继续执行,有以下两种方法: 1...
  • 这几天,写服务器代码过程当中,遇见EINRT信号的问题,我是借鉴 《unp ...下面是我查找到的和EINTR有关的介绍: 1 http://blog.csdn.net/yanook/article/details/7226019  慢系统调用函数如何处理中断信号EINTR 2
  • 这几天,写服务器代码过程当中,遇见EINTR信号的问题,我是借鉴 《unp 》,采用continue或者goto again循环解决的。但是感觉这个还是很有必要记录一下。网络上查找到的信息很多。下面是我查找到的和EINTR有关的介绍...
  • socket中的函数遇见EINTR的处理

    千次阅读 2016-12-05 17:04:38
    这几天,写服务器代码过程当中,遇见EINRT信号的问题,我是借鉴 《unp ...下面是我查找到的和EINTR有关的介绍: 1 http://blog.csdn.net/yanook/article/details/7226019  慢系统调用函数如何处理中断信号EINTR 2
  • 目录 人为重启被中断的系统调用 安装信号时设置 SA_RESTART属性 忽略信号 永远阻塞的系统调用,被信号中断,导致其不继续等待,转而去执行signal_handler 1、什么是慢系统调用?...该术语适用于那些可能永远阻塞的...
  • errno!=EINTR

    千次阅读 2013-10-21 20:39:01
    =EINTR注意read()如果读到数据为0,那么就表示文件结束了,如果在读的过程中遇到了中断那么会返回-1,同时置errno为EINTR。 因此判断read的条件: 如果read返回如果==0 表示文件结束, 处理 如果<0 && errno==...
  • select EINTR

    千次阅读 2015-03-05 18:00:58
    select 会被定时器产生的EINTR中断 在定时器的设置中增加了SA_RESTART和sigprocmask,发现都不管用 只能自己判断EINTR来重启select了。 在select被EINTR中断时,我输出一条打印信息然后重启select 发现一个...
  • linux下EINTR的错误处理

    千次阅读 2016-05-15 20:20:41
    慢系统调用(slow system call):此术语适用于那些可能永远阻塞的...EINTR错误的产生:当阻塞于某个慢系统调用的一个进程捕获某个信号且相应信号处理函数返回时,该系统调用可能返回一个EINTR错误。例如:在socket服务器
  • EINTR返回值到处理

    千次阅读 2014-12-24 17:54:47
    在《UNIX Networking programming》Chapte5中论述了“slow system call"的概念, 而且给出了EINTR的处理方法。 慢系统调用(slow system call):此术语适用于那些可能永远阻塞的系统调用。永远阻塞的系统调用是指...
  • EINTR的处理

    千次阅读 2011-06-16 09:34:00
    此时,系统调用会返回-1,并且错误码被置为EINTR.但是,有时并不将这样的情况作为错误.有两种处理方法:1.如果错误码为EINTR则重新调用系统调用,例如Postgresql中有一段代码: (){dp.sh.Toolbar.Command(ViewSource,thi
  • linux中对EINTR错误的处理

    千次阅读 2012-08-24 15:59:49
    慢系统调用(slow system call):此术语适用于那些可能永远阻塞的系统...EINTR错误的产生:当阻塞于某个慢系统调用的一个进程捕获某个信号且相应信号处理函数返回时,该系统调用可能返回一个EINTR错误。例如:在socket服

空空如也

1 2 3 4 5 ... 20
收藏数 25,772
精华内容 10,308
关键字:

eintr