mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Peter T. Breuer" <ptb@it.uc3m.es>
To: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
Cc: ptb@it.uc3m.es, lar@cs.york.ac.uk,
	"Linux Kernel" <linux-kernel@vger.kernel.org>
Subject: Re: [OT] Interrupting select.
Date: Thu, 3 May 2001 01:03:06 +0200 (MET DST)	[thread overview]
Message-ID: <200105022303.f42N36825429@oboe.it.uc3m.es> (raw)
In-Reply-To: <E14v4zq-0004Sy-00@the-village.bc.nu> from "Alan Cox" at "May 2, 2001 11:21:19 pm"

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UNKNOWN-8BIT, Size: 1862 bytes --]

"A month of sundays ago Alan Cox wrote:"
> > What IS the magic combination that makes select interruptible
> > by honest-to-goodness non-blocked signals!
> man
> 
> [seriously man sigaction]

Equally seriously .. all signals are unblocked in my code and always
have been. The processes receive signals vurrrrry happily. Except when
they are in a select-with-timeout loop, when they keep going round the
loop poking their head out of the select every 5s, and taking no notice
of the murderous hail of die die die die die stuff being slammed at
them.

You can see stuff such as the following early on in my code:

           // handle every s¡ngle signal in one "sighandler"
           for (k = 1; k < 30; k++) {
             struct sigaction sa = { {sighandler}, {{0}}, SA_RESTART, NULL };
             sigfillset(& sa.sa_mask);
             sigaction(k, & sa, NULL);
           }
                                                     
But does select come out of this loop?

             while (1) {
                 int res = select(n,rfds,wfds,efds,&timeout);
                 if (res > 0)
                    return res;    // data or error is expected
                 if (res == 0) {
                    return -ETIME; // timeo in select
                 }
             }

A resounding "no". kill -9 hurts it but it's invulnerable to everything
else.

Looking at the kernel code in select.c. I see it's implemented by poll
(I knew that). sys_select calls do_select and I can't for the life of
me see where anyone sets a signal mask. OTOH if all signals are
masked by default when syscalls are made (I don't know, but it seems
possible) then I can't see where interrupts are allowed again.

The man page for select says nothing about it being interruptible, or
not. 

This has been in the back of my mind for months. I'm glad somebody
asked about it!


Peter

  reply	other threads:[~2001-05-02 23:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-02 21:46 Laramie Leavitt
2001-05-02 21:56 ` Peter T. Breuer
2001-05-02 22:21   ` Alan Cox
2001-05-02 23:03     ` Peter T. Breuer [this message]
2001-05-03  0:01       ` Alan Cox
2001-05-04 20:59       ` Olaf Dietsche
2001-05-02 23:44 Peter T. Breuer
2001-05-06 16:44 ` Stephen Wille Padnos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200105022303.f42N36825429@oboe.it.uc3m.es \
    --to=ptb@it.uc3m.es \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=lar@cs.york.ac.uk \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®