mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mike Jagdis <jaggy@purplet.demon.co.uk>
To: root@chaos.analogic.com
Cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: Behavior of poll() within a module
Date: Tue, 23 Oct 2001 14:33:21 +0100	[thread overview]
Message-ID: <3BD571A1.1000009@purplet.demon.co.uk> (raw)
In-Reply-To: <Pine.LNX.3.95.1011023085214.9875A-100000@chaos.analogic.com>

Richard B. Johnson wrote:
> What is the intended behavior of poll within a module when
> two or more tasks are sleeping in poll? Specifically, when
> wake_up_interruptible is executed from a module, are all
> tasks awakened or is only one? If only one, is it the
> first task to call poll/select or the last, which is awakened
> first? 

Normally all but... In the case of accept() the kernel knows
that a woken up process will service the event (the code is
all in the kernel) so the accept code flags its wait_queue
entry to say, "If this gets woken don't wake the rest".
Unfortunately the way wake one and wake all semantics are
handled within the wait queue mean we get FIFO rather than
LIFO behaviour I believe :-(

I guess you could do "the accept() thing" yourself from a
module - or add a Linux specific poll flag and do it from
user space for that matter.

Oh, and yes, wake all is required behaviour of poll/select.
It's just accept that is special because all the code is in
the kernel and if it gets woken we _know_ that event is no
longer present.

				Mike


  reply	other threads:[~2001-10-23 13:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-23 12:53 Richard B. Johnson
2001-10-23 13:33 ` Mike Jagdis [this message]
2001-10-23 14:13   ` Richard B. Johnson
2001-10-24  9:52     ` Mike Jagdis
2001-10-23 15:58 Manfred Spraul
2001-10-23 17:17 ` Richard B. Johnson
2001-10-23 18:02   ` Manfred Spraul
2001-10-23 18:16     ` Richard B. Johnson

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=3BD571A1.1000009@purplet.demon.co.uk \
    --to=jaggy@purplet.demon.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    /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®