select() & signals

select() & signals

Post by Maarten D. de Jo » Mon, 23 Feb 1998 04:00:00



I am porting a Linux-program to my Amiga. The program makes use of select()
and a few signals in its main loop. Since Amiga-signals and Linux-signals
are rather different, I need to rewrite it. However, I need to know which
signals stop select(). I know that SIGALRM breaks the waiting, but how about
the other 29 signals?

Maarten

 
 
 

select() & signals

Post by Neil Moor » Wed, 25 Feb 1998 04:00:00



Quote:> I am porting a Linux-program to my Amiga. The program makes use of select()
> and a few signals in its main loop. Since Amiga-signals and Linux-signals
> are rather different, I need to rewrite it. However, I need to know which
> signals stop select(). I know that SIGALRM breaks the waiting, but how about
> the other 29 signals?

  On Linux, all non-blocked, non-ignored signals stop select(2) --
even if that signal has SA_RESTART specified.  This is BSD-derived
behaviour; things are different on SysV Unices.  For more information,
see _Advanced_Programming_in_the_UNIX_Environment_ [Stevens 1990] and
sigaction(3).

--

  Say something nice to at least four people today.  Read Matthew 5:44, too.
    ``You were sick, but now you're well again, and there's work to do.''
                                                   ---Kilgore Trout

 
 
 

select() & signals

Post by Ross Osbo » Thu, 26 Feb 1998 04:00:00



Quote:>   On Linux, all non-blocked, non-ignored signals stop select(2) --
> even if that signal has SA_RESTART specified.  This is BSD-derived
> behaviour; things are different on SysV Unices.  For more information,
> see _Advanced_Programming_in_the_UNIX_Environment_ [Stevens 1990] and
> sigaction(3).

I wish I had read this before I posted to comp.os.linux but I guess
I'll bring it up here as well.

According to the man page (sigaction(2) on my system, not sigaction(3))
SA_RESTART has a totally different meaning than what SysV and BSD give
it.  I don't see any flags for controlling whether an interrupted
system call gets restarted or not.

I also questioned whether the SA_ONESHOT default behavior made it not
POSIX compliant.  I have not read the POSIX spec but according to
Stevens:

    "Unlike earlier systems with their unreliable signals, POSIX.1
        requires that a signal handler remain installed until explicitly
        changed."

To get this behavior on Linux you would have to use the SA_RESTART
flag which is non-portable.

Can anybody explain why the default behavior and flags were chosen
this way?

Ross

 
 
 

select() & signals

Post by Stephen C. Tweed » Sat, 28 Feb 1998 04:00:00


Hi,



> >   On Linux, all non-blocked, non-ignored signals stop select(2) --
> > even if that signal has SA_RESTART specified.  This is BSD-derived
> > behaviour; things are different on SysV Unices.  For more information,
> > see _Advanced_Programming_in_the_UNIX_Environment_ [Stevens 1990] and
> > sigaction(3).

> I wish I had read this before I posted to comp.os.linux but I guess
> I'll bring it up here as well.

> According to the man page (sigaction(2) on my system, not sigaction(3))
> SA_RESTART has a totally different meaning than what SysV and BSD give
> it.  I don't see any flags for controlling whether an interrupted
> system call gets restarted or not.

man 2 sigaction:

              SA_RESTART
                     Provide behaviour compatible with BSD signal
                     semantics  by  making  certain  system calls
                     restartable across signals.

Quote:> I also questioned whether the SA_ONESHOT default behavior made it not
> POSIX compliant.  I have not read the POSIX spec but according to
> Stevens:

>     "Unlike earlier systems with their unreliable signals, POSIX.1
>    requires that a signal handler remain installed until explicitly
>    changed."

> To get this behavior on Linux you would have to use the SA_RESTART
> flag which is non-portable.

              SA_ONESHOT or SA_RESETHAND
                     Restore  the  signal  action  to the default
                     state  once  the  signal  handler  has  been
                     called.   (This  is  the default behavior of
                     the signal(2) system call.)

sigaction(2) defaults to persistant signal handlers, signal(2)
defaults to one-shot.

Quote:> Can anybody explain why the default behavior and flags were chosen
> this way?

It seems to make sense to me --- perhaps your man pages are out of date?

Cheers,
 Stephen.

 
 
 

1. signal 4 & signal 11

Hi

i got a problem running X (oh really?)
at first i thought it was my mouse (serial 2 button)
since it's was messed up when ever the error happend
and i had to plug it out and plug it in again
but now that i bought a new mouse (serial 3 button)
there's no problem with the mouse
but i still get something like this:

caught signal 11
conection to X server lost

 sometimes it says '4'...think it was when it was set to 8bpp only... though
having more resolutions to chose from should'nt change the error msg. or
what?

i don't think it's a problem with my gfx card since it's listed in the setup
(Diamond Edge 3D)

it would be nice if you could email your answer too
thanx

Geekster

2. 2.2.2 install hangs on vx0 probe

3. select()==1 && read()==-1, EIO

4. Load Balancing

5. Q: select and signal

6. centralizing .cshrc and .login files

7. select and signal

8. Installing AppleTalk (CAP)

9. ptrace/select/signal errno weirdness

10. using signal to (portably) wake up a select call

11. 'select' failure or signal should not update timeout

12. signals cause select to return -1 and errno = 0?

13. select call and signal call