All of lore.kernel.org
 help / color / mirror / Atom feed
From: lkv@isg.de
To: alan@lxorguk.ukuu.org.uk, "Kernel, Linux" <linux-kernel@vger.kernel.org>
Subject: Re: Desperately missing a working "pselect()" or similar...
Date: Mon, 08 Oct 2001 18:32:06 +0200	[thread overview]
Message-ID: <3BC1D506.E68B9DB2@isg.de> (raw)


> > The select system call doesn't return EINTR when the signal is caught
> > prior to entry into select.
> 
> Your friend there is siglongjmp/sigsetjmp - the same problem was true
> with old versions of alarm that did
> 
>         alarm(num)
>         pause()
> 
> on a heavily loaded box.
> 
> Using siglongjmp cures that

Hmmm... would you say the "siglongjmp" method is better than the "self-pipe"
method for a select on both file descriptors and signals too?

As far as I can see the trade-off is (in the non-race-condition case)
between having to call read() on the pipe (to empty it after receiving the
signal) for the "self-pipe" method and having to call sigsetjump() every time
before one enters select/poll.

My assumption would be that the "self-pipe" method is cheaper... right?

Then somebody mentioned using signals to wake up processes
for frequent events wouldn't be a good idea at all - why?
And what could be a better alternative given that there are N processes,
which all need to be able to wake up any of the other N-1 processes - where N
is big enough to prohibit dedicated channels between each possible process
pair, and given that it has to be a portable way that does not impose
the risk of leaking files to a disk?

Regards,

Lutz Vieweg

--
 Dipl. Phys. Lutz Vieweg | email: lkv@isg.de
 Innovative Software AG  | Phone/Fax: +49-69-505030 -120/-505
 Feuerbachstrasse 26-32  | http://www.isg.de/people/lkv/
 60325 Frankfurt am Main | ^^^ PGP key available here ^^^

             reply	other threads:[~2001-10-08 16:31 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-08 16:32 lkv [this message]
2001-10-08 16:44 ` Desperately missing a working "pselect()" or similar Alan Cox
2001-10-08 17:06   ` lkv
2001-10-08 17:24     ` Alan Cox
2001-10-09 13:37 ` Jan Hudec
2001-10-13 16:05   ` Jamie Lokier
  -- strict thread matches above, loose matches on Subject: below --
2001-10-05 15:36 lkv
2001-10-05 16:19 ` Alexander Viro
2001-10-05 16:28   ` lkv
2001-10-05 16:36 ` Christopher Friesen
2001-10-05 16:40   ` lkv
2001-10-05 20:37 ` Bernd Eckenfels
2001-10-05 23:05   ` Alex Pennace
2001-10-05 23:13     ` Alan Cox
2001-10-05 23:52       ` Alex Pennace
2001-10-05 23:22     ` Neil Brown
2001-10-05 23:30       ` Alex Pennace
2001-10-05 23:43         ` David Schwartz
2001-10-06  0:03       ` Alan Cox

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=3BC1D506.E68B9DB2@isg.de \
    --to=lkv@isg.de \
    --cc=alan@lxorguk.ukuu.org.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.