4 ms·

The big problem is; if you have a thread reading from a socket, how can you ever interrupt it if you wish to do so? EINTR on signals is really not so bad when y

The big problem is; if you have a thread reading from a socket, how can you ever interrupt it if you wish to do so? EINTR on signals is really not so bad when you think of it from that angle. (If you don't want to deal with EINTR everywhere, you can block the signals and use e.g. epoll_pwait() to temporarily unblock them at opportune moments. Or you can set SA_RESTART when setting up the signal handler if you do not ever wish this behavior.) For regular files, Linux has a simple solution for you: You'll never get EINTR. It's only a thing for sockets, pipes and other things that can block indefinitely, which a file cannot. (Except if you're on NFS, in which case you have to choose between two evils depending on whether your file system is mounted intr or nointr :-) )

pjc50 3y ago
"nointr", last time I used it, meant your program could never be interrupted by NFS errors under any circumstances. Therefore, if the NFS master went away, your program couldn't be killed either and would be stuck in D state forever until you rebooted the whole NFS client machine.
- Sesse__ 3y ago
  Yes, that's the big evil on that side. :-) (You don't need to reboot, though; you can “mount -o remount,intr …” to switch states and then kill. I wonder if you can also now actually do kill -9 specifically even on nointr, but I haven't checked.)
  - prewett 3y ago
    In my experience (admittedly from some years ago), you have to be pretty careful about using the terminal when NFS fails, since you can pretty easily lock up your terminal, of which you only have a "fixed" supply. If you're using NFS, chances are good your home directory is on NFS so you need to make sure you don't accidentally stat() something in the current path (which is probably in your home directory). Obviously, starting new terminal sessions once you've locked one up isn't going to happen. But you'll probably waste a couple trying to figure out what's going on. You'll also want to have that mount command written on a piece of paper somewhere (and remember that you have it), since you can't read your notes.txt file in your home directory. You probably can't do a web search, since the browser reads/writes a cache to your home directory. (Maybe lynx or links would work?) Hopefully you didn't add ~/bin or an NFS-mounted /opt or something before the system paths or you'll need to do run everything with the full path. But... a bunch of tool installers like to prepend their directory to your path if you let them fix everything automatically. I have a ~/.gem/ruby/2.3.0/bin early in my path right now, completely didn't realize.
- vincent-manis 3y ago
  I haven't used NFS in decades; back in the day (we had Sun-3's running SunOS), when an NFS server hung, we got a message like `NFS server foo not responding, still trying' over and over again. In the absence of an admin, all you could do was to login again on a different machine. We called it the `Notwork File System'.
- pjmlp 3y ago
  The joy of trying to login into UNIX thin terminals with the home directory mounted via NFS and having the network cable with a broken terminator. before ethernet became a thing.
crabbone 3y ago
You kind of put the cart before the horse... Threads are the coping mechanism, that has to cope with signals, not the other way around. Threads exist in the way they are because of the original bad design (which included signals). Potentially, there could be other ways of dealing with communication, some of them already exist in popular operating systems, s.a. sockets. It's actually funny that you mention one in your problem statement. Erlang-style ports are another possible solution.
- Sesse__ 3y ago
  Replace “thread” with “process”, then. The basic fact doesn't really change; if you want a clean shutdown on Ctrl-C, you'll need to allow an EINTR-like return from a blocking syscall.
spacechild1 3y ago
> The big problem is; if you have a thread reading from a socket, how can you ever interrupt it if you wish to do so? Poll + an eventfd (or another socket). IMO, signals create more problems than they solve.
- Sesse__ 3y ago
  Well, that's outlawing blocking I/O. Replacing every blocking I/O call with a poll() loop creates significantly more boilerplate than EINTR does…
  - spacechild1 3y ago
    > Well, that's outlawing blocking I/O Not really. A blocking poll() call on a single socket (+ eventfd) is still blocking I/O.
dannymi 3y ago
>The big problem is; if you have a thread reading from a socket, how can you ever interrupt it if you wish to do so? EINTR on signals is really not so bad when you think of it from that angle. Yeah, but what if the thread is not currently blocked and you want to interrupt it / stop the thread? Unfortunately, it doesn't queue the EINTR for the next blocking function if the thread was NOT blocked at the moment the signal was sent.
- meindnoch 3y ago
  So what is the proper solution for this in POSIX?

pjc50 3y ago

"nointr", last time I used it, meant your program could never be interrupted by NFS errors under any circumstances. Therefore, if the NFS master went away, your program couldn't be killed either and would be stuck in D state forever until you rebooted the whole NFS client machine.

Sesse__ 3y ago
Yes, that's the big evil on that side. :-) (You don't need to reboot, though; you can “mount -o remount,intr …” to switch states and then kill. I wonder if you can also now actually do kill -9 specifically even on nointr, but I haven't checked.)
- prewett 3y ago
  In my experience (admittedly from some years ago), you have to be pretty careful about using the terminal when NFS fails, since you can pretty easily lock up your terminal, of which you only have a "fixed" supply. If you're using NFS, chances are good your home directory is on NFS so you need to make sure you don't accidentally stat() something in the current path (which is probably in your home directory). Obviously, starting new terminal sessions once you've locked one up isn't going to happen. But you'll probably waste a couple trying to figure out what's going on. You'll also want to have that mount command written on a piece of paper somewhere (and remember that you have it), since you can't read your notes.txt file in your home directory. You probably can't do a web search, since the browser reads/writes a cache to your home directory. (Maybe lynx or links would work?) Hopefully you didn't add ~/bin or an NFS-mounted /opt or something before the system paths or you'll need to do run everything with the full path. But... a bunch of tool installers like to prepend their directory to your path if you let them fix everything automatically. I have a ~/.gem/ruby/2.3.0/bin early in my path right now, completely didn't realize.
vincent-manis 3y ago
I haven't used NFS in decades; back in the day (we had Sun-3's running SunOS), when an NFS server hung, we got a message like `NFS server foo not responding, still trying' over and over again. In the absence of an admin, all you could do was to login again on a different machine. We called it the `Notwork File System'.
pjmlp 3y ago
The joy of trying to login into UNIX thin terminals with the home directory mounted via NFS and having the network cable with a broken terminator. before ethernet became a thing.

crabbone 3y ago

You kind of put the cart before the horse... Threads are the coping mechanism, that has to cope with signals, not the other way around. Threads exist in the way they are because of the original bad design (which included signals). Potentially, there could be other ways of dealing with communication, some of them already exist in popular operating systems, s.a. sockets. It's actually funny that you mention one in your problem statement. Erlang-style ports are another possible solution.

Sesse__ 3y ago
Replace “thread” with “process”, then. The basic fact doesn't really change; if you want a clean shutdown on Ctrl-C, you'll need to allow an EINTR-like return from a blocking syscall.

spacechild1 3y ago

> The big problem is; if you have a thread reading from a socket, how can you ever interrupt it if you wish to do so? Poll + an eventfd (or another socket). IMO, signals create more problems than they solve.

Sesse__ 3y ago
Well, that's outlawing blocking I/O. Replacing every blocking I/O call with a poll() loop creates significantly more boilerplate than EINTR does…
- spacechild1 3y ago
  > Well, that's outlawing blocking I/O Not really. A blocking poll() call on a single socket (+ eventfd) is still blocking I/O.

dannymi 3y ago

>The big problem is; if you have a thread reading from a socket, how can you ever interrupt it if you wish to do so? EINTR on signals is really not so bad when you think of it from that angle. Yeah, but what if the thread is not currently blocked and you want to interrupt it / stop the thread? Unfortunately, it doesn't queue the EINTR for the next blocking function if the thread was NOT blocked at the moment the signal was sent.

meindnoch 3y ago
So what is the proper solution for this in POSIX?