Professional Web Applications Themes

EINTR and open () - UNIX Programming

I'm working on a small xml batch file loader and I have a question: If the open () function failes and errno is set to EINTR should I try again until is passes or failes for some other reason? Is this a "good" way to handle EINTR? Thanks...

  1. #1

    Default EINTR and open ()

    I'm working on a small xml batch file loader
    and I have a question:

    If the open () function failes and errno is set
    to EINTR should I try again until is passes or
    failes for some other reason?

    Is this a "good" way to handle EINTR?

    Thanks
    isillight Guest

  2. #2

    Default Re: EINTR and open ()

    Yes, but it won't happen if you are opening a file because, in that
    case, open() is uninterruptible. You wouldn't "normally" expect a signal
    to arrive during an open() in any case.

    isillight wrote: 
    Robert Guest

  3. #3

    Default Re: EINTR and open ()

    Robert Harris <co.uk> wrote: 
    >
    > Yes, but it won't happen if you are opening a file because, in that
    > case, open() is uninterruptible. You wouldn't "normally" expect a signal
    > to arrive during an open() in any case.[/ref]

    Why shouldn't a signal arrive when you call open(), being it for a
    normal file or a device file, so why do you think it's uninterrupt-
    ible? Since signals happen asynchronously I can't see what should
    protect an open() of just a normal file, especially without knowing
    where the file resides.

    In place of the OP I would simply again call open() until it succeeds
    (or returns with some other error), of course unless receipt of the
    signal has some special meaning that would make continuing with
    opening the file useless.
    Regards, Jens
    --
    \ Jens Thoms Toerring ___ fu-berlin.de
    \__________________________ http://www.toerring.de
    Jens.Toerring@physik.fu-berlin.de Guest

  4. #4

    Default Re: EINTR and open ()

    Ah! Well, traditionally system calls are either "slow" or "fast" -
    "slow" ones are those that can block for ever. (I am quoting from
    "Advanced Programming in the UNIX Environment" by W Richard Stevens).
    "slow" calls are interruptible, "fast" ones are not.

    Signals can only be accepted by processes while they are in functions
    that are "interruptible".

    And even otherwise interruptible calls may restart after a signal is
    accepted rather than return -1 with EINTR set, depending on the
    disposition of the SA_RESTART flag for that signal.

    Robert

    fu-berlin.de wrote: 
    >>
    >>Yes, but it won't happen if you are opening a file because, in that
    >>case, open() is uninterruptible. You wouldn't "normally" expect a signal
    >>to arrive during an open() in any case.[/ref]
    >
    >
    > Why shouldn't a signal arrive when you call open(), being it for a
    > normal file or a device file, so why do you think it's uninterrupt-
    > ible? Since signals happen asynchronously I can't see what should
    > protect an open() of just a normal file, especially without knowing
    > where the file resides.
    >
    > In place of the OP I would simply again call open() until it succeeds
    > (or returns with some other error), of course unless receipt of the
    > signal has some special meaning that would make continuing with
    > opening the file useless.
    > Regards, Jens[/ref]
    Robert Guest

  5. #5

    Default Re: EINTR and open ()

    Robert Harris <co.uk> wrote: 
     

    But does this make every open() of a "normal" file uninterruptible?
    I am wondering about cases where the file to open e.g. resides on
    a NFS-mounted disk. Wouldn't that qualify as a "slow" system call
    - if no proper timeouts are set for the NFS connection it could
    block forever, coudn't it?
     

    Yes, of course, as long as the OP has an handler installed for the
    particular signal s/he's getting.
    Regards, Jens
    --
    \ Jens Thoms Toerring ___ fu-berlin.de
    \__________________________ http://www.toerring.de
    Jens.Toerring@physik.fu-berlin.de Guest

  6. #6

    Default Re: EINTR and open ()

    <fu-berlin.de> wrote in message
    news:c10mph$1ch16f$de... [/ref]
     [/ref]
     

    No, it does not. And it would be a design flaw to assume that opening a
    file will be an uninterruptible operation even though it is quite likely to
    be.
     


    Sure. Opening a serial port could certainly be a slow system call too.

    DS




    David Guest

  7. #7

    Default Re: EINTR and open ()



    David Schwartz wrote:
     [/ref]
    >
    >  [/ref]
    >
    >  
    >
    >
    > No, it does not. And it would be a design flaw to assume that opening a
    > file will be an uninterruptible operation even though it is quite likely to
    > be.[/ref]

    As a matter of fact it is likely to be interrupted.

    Take as an example the open a fully qualified path name.

    "/" must be read to find the name of the next directory down
    get it's node number.

    The process is repeated for every directory in the
    fully qualified pathname. This may involve several
    physical disk reads which are on the order of
    milliseconds. Thus, open is a "blocking" system
    call which may get interrupted while the disk is
    being read.

     
    >
    >
    >
    > Sure. Opening a serial port could certainly be a slow system call too.
    >
    > DS
    >
    >
    >
    > [/ref]

    --

    "It is impossible to make anything foolproof because fools are so
    ingenious" - A. Bloch

    Nick Guest

  8. #8

    Default Re: EINTR and open ()

    On Wed, 18 Feb 2004 14:24:36 -0800,
    David Schwartz <com> wrote:

     
     
    >
    >
    > Sure. Opening a serial port could certainly be a slow system call too.
    >[/ref]


    Especialy when the open() call is suspended until DCD is detected on the
    modem port. Traditional NFS calls are uninterruptible with the effect
    that if the NFS server is down the process trying to access it isn't
    killable until the NFS server is back online. Usualy there is a mount
    option to change this behaviour with the usual warning to only do this
    if the NFS file system is mounted read-only.


    Villy
    Villy Guest

  9. #9

    Default Re: EINTR and open ()

    Robert Harris <co.uk> writes: 
     
    >
    > Yes, but it won't happen if you are opening a file because, in that
    > case, open() is uninterruptible. You wouldn't "normally" expect a
    > signal to arrive during an open() in any case.[/ref]

    I've had EINTR from open() on a regular file, even when when the
    relevant signal handler was set with SA_RESTART. I think you're being
    optimistic.

    --
    http://www.greenend.org.uk/rjk/
    Richard Guest

Similar Threads

  1. #25886 [Com]: failed to open stream: Too many open files in Unknown on line 0
    By michel dot jansens at ulb dot ac dot be in forum PHP Development
    Replies: 0
    Last Post: October 17th, 07:14 AM
  2. #25886 [Bgs]: failed to open stream: Too many open files in Unknown on line 0
    By padair at pntsi dot ca in forum PHP Development
    Replies: 1
    Last Post: October 16th, 03:41 PM
  3. Replies: 0
    Last Post: October 16th, 04:54 AM
  4. #25886 [NEW]: failed to open stream: Too many open files in Unknown on line 0
    By padair at pntsi dot ca in forum PHP Development
    Replies: 0
    Last Post: October 16th, 04:10 AM
  5. Why fopen fail because of EINTR?
    By Geoff Clare in forum UNIX Programming
    Replies: 1
    Last Post: June 24th, 12:52 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139