* [TUHS] "Slow system call" and EINTR
2012-03-01 23:29 [TUHS] "Slow system call" and EINTR Dan Stromberg
@ 2012-03-01 23:59 ` ramble1035 @dslextreme.com
0 siblings, 0 replies; 2+ messages in thread
From: ramble1035 @dslextreme.com @ 2012-03-01 23:59 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 2+ messages in thread