3 ms·

There are certain race conditions if you rely on signals to interrupt system calls and the interrupt happens before the syscall is called (after setting the sig

by calloc 15y ago

There are certain race conditions if you rely on signals to interrupt system calls and the interrupt happens before the syscall is called (after setting the signal, but before the syscall happens). Since your code could have been anywhere in the execution path you can only do very limited amount of things within the signal handler that won't cause catastrophic issues otherwise.

javert 15y ago
certain race conditions if you rely on signals to interrupt system calls and the interrupt happens before the syscall is called I'm pretty familiar with signals, but I don't really know what the problem is here. Why would you rely on signals to interrupt system calls? Maybe if I know why you would do that, I will see why it's a problem if the signal comes before the syscall happens.
- spc476 15y ago
  At work, we have a time-critical program. In that program, we need to lock a file in order to modify it safely. The files themselves are stored on NFS (don't ask---this was a design decision from long ago). fcntl() (used to lock files) does not include a timeout. We need a timeout because the program is time-critical. NFS is not a local filesystem, but across the network. If the network is flaky, we don't want to hang on locking the file. So we have to rely upon SIGALRM (via setitimer()) to interrupt the fcntl() call so we don't hang indefinitely.
  - javert 15y ago
    Interesting, thanks.
- javert 15y ago
  Wow, I cannot fathom how I could be downvoted on an honest and purely technical question.
- X-Istence 15y ago
  The examples given in the article linked explain this pretty well actually... For example, lets say you want Ctrl + C to quit the program (bare with me, very simple example), and you have a select() call. So you set up your signal handlers, and then start filling the required structures for the select() call, before select() is called though you receive a SIGINT, your signal handler simply sets a global flag that is checked when select() returns (with errno == EINTR). So now the flag is set, the handler has done its job, and select() gets called and your program now starts waiting on file descriptors. What you really wanted to happen is that the program would see the flag, clean up nicely and quit. Now the user has to send a second Ctrl + C to interrupt the select() syscall and to have the code executed that checks for errno == EINTR and the global flag that was set in the signal handler. This is but a simple example of a race condition that can exist. The SIGALRM example given by the other HN user is also an excellent example of when things can go awry when not intentioned, and unless you program your signal handlers with that in mind you may get results you weren't expecting.
  - javert 15y ago
    Thanks. That example doesn't live up to the hype that was mentioned by a previous poster and that had me worried. However, that hype was probably overstated. For example, "there are certain race conditions if you rely on signals to interrupt system calls and the interrupt happens before the syscall is called" -> seems to imply there are race conditions inherent to the situation, not race conditions that can be introduced by programmer mistake (which is pretty obvious, IMO). Also "since your code could have been anywhere in the execution path you can only do very limited amount of things within the signal handler that won't cause catastrophic issues otherwise" -> I just don't believe that; you can do lots of things in the signal handler if you know what you're doing.
    - calloc 15y ago
      Sure, you can do lots of things in the signal handler, if you are careful, but that is the point, it is more likely you will make a mistake than not. It is very simple to think, let me add this to the signal handler it will make my life easier and cause all kinds of weird issues that happen randomly like a heisenbug...

by calloc 15y ago

javert 15y ago

certain race conditions if you rely on signals to interrupt system calls and the interrupt happens before the syscall is called I'm pretty familiar with signals, but I don't really know what the problem is here. Why would you rely on signals to interrupt system calls? Maybe if I know why you would do that, I will see why it's a problem if the signal comes before the syscall happens.

spc476 15y ago
At work, we have a time-critical program. In that program, we need to lock a file in order to modify it safely. The files themselves are stored on NFS (don't ask---this was a design decision from long ago). fcntl() (used to lock files) does not include a timeout. We need a timeout because the program is time-critical. NFS is not a local filesystem, but across the network. If the network is flaky, we don't want to hang on locking the file. So we have to rely upon SIGALRM (via setitimer()) to interrupt the fcntl() call so we don't hang indefinitely.
- javert 15y ago
  Interesting, thanks.
javert 15y ago
Wow, I cannot fathom how I could be downvoted on an honest and purely technical question.
X-Istence 15y ago
The examples given in the article linked explain this pretty well actually... For example, lets say you want Ctrl + C to quit the program (bare with me, very simple example), and you have a select() call. So you set up your signal handlers, and then start filling the required structures for the select() call, before select() is called though you receive a SIGINT, your signal handler simply sets a global flag that is checked when select() returns (with errno == EINTR). So now the flag is set, the handler has done its job, and select() gets called and your program now starts waiting on file descriptors. What you really wanted to happen is that the program would see the flag, clean up nicely and quit. Now the user has to send a second Ctrl + C to interrupt the select() syscall and to have the code executed that checks for errno == EINTR and the global flag that was set in the signal handler. This is but a simple example of a race condition that can exist. The SIGALRM example given by the other HN user is also an excellent example of when things can go awry when not intentioned, and unless you program your signal handlers with that in mind you may get results you weren't expecting.
- javert 15y ago
  Thanks. That example doesn't live up to the hype that was mentioned by a previous poster and that had me worried. However, that hype was probably overstated. For example, "there are certain race conditions if you rely on signals to interrupt system calls and the interrupt happens before the syscall is called" -> seems to imply there are race conditions inherent to the situation, not race conditions that can be introduced by programmer mistake (which is pretty obvious, IMO). Also "since your code could have been anywhere in the execution path you can only do very limited amount of things within the signal handler that won't cause catastrophic issues otherwise" -> I just don't believe that; you can do lots of things in the signal handler if you know what you're doing.
  - calloc 15y ago
    Sure, you can do lots of things in the signal handler, if you are careful, but that is the point, it is more likely you will make a mistake than not. It is very simple to think, let me add this to the signal handler it will make my life easier and cause all kinds of weird issues that happen randomly like a heisenbug...