[TUHS] "Slow system call" and EINTR

[ramble1035@dslextreme.com (ramble1035 @dslextreme.com)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]

On Thu, Mar 1, 2012 at 3:29 PM, Dan Stromberg <drsalists at gmail.com> wrote:
>
> I gather system calls can return EINTR only when they are "slow".  True?

For a unique definition of "slow"...  :)

> What makes a system call "slow"?  Is it the ability to block for a while?
> But I wouldn't think dup(2) would block, for example.

From my experience, a slow vs fast call is only partially based on
time.  It's more based on obtaining and releasing resources.

A slow system call is one that might take a long time, and any
resource allocations requested during the system call processing can
be easily undone (returned).  TTY input, as an example.

Things like a disk request are *supposed* to be quick, but even if
they're not, they involve allocating buffers, queueing disk requests,
setting up possible interrupts or DMA, and other messy internal
details.  Aborting a pending disk request would be a substantial
amount of effort.  Thus, a disk request cannot be interrupted and it's
classified as "fast".  (or "not slow")

This presents a few difficulties when you consider something like NFS,
which acts like a disk request until it gets down to the network
layer, where things might well take a long time.  But interrupting and
aborting this is not easy, which is why some NFS requests, when hung,
stay hung even when you bang on Control-C for a while.

Really simple things like dup, which involves a simple copy, would
probably not block unless there were extreme issues with memory
allocation or something.

  -- Chris