mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Ulrich Drepper" <drepper@gmail.com>
To: "Davide Libenzi" <davidel@xmailserver.org>
Cc: "Davi Arnaut" <davi@haxent.com.br>,
	"Eric Dumazet" <dada1@cosmosbay.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [patch 14/22] pollfs: pollable futex
Date: Fri, 4 May 2007 16:38:21 -0700	[thread overview]
Message-ID: <a36005b50705041638h37cd0654q442e7d50f1e63040@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0705041201390.6958@alien.or.mcafeemobile.com>

On 5/4/07, Davide Libenzi <davidel@xmailserver.org> wrote:
> This is a pretty specific case, that is not very typical to find in the
> usual common event loop dispatch application design.

This is where you are very wrong.  Yes, it's rare in the Unix world
because non-trivial programs cannot implement this in most cases with
the available infrastructure.  But it is very common in other places
and what is more, it makes a lot of sense.  It gives you scalability
with the size of the machines at no cost associated to reorganizing
the program.


> And if you *really* want your truly generic WaitForMultipleObjects
> implementation, your only way is to base it on files. Files are our almost
> perfect match to HANDLEs in our world. We have the basic infrastructure
> already there.

"basic", but not complete.  And I never said that the implementation
thye have is perfect, far from it.  The concept is good and if we now
can implement it, with all the event sources available, using an
efficient event delivery mechanism we are far ahead of their design.

The proposal now  on the table doesn't bring us there all the way and
it has the potential to make future work in the area of event delivery
harder just because there is more legacy code to be kept  happy.  This
is why I propose to not consider these changes and instead go for the
gold, i.e., the full solution.

  parent reply	other threads:[~2007-05-04 23:40 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-02  5:22 [patch 00/22] pollfs: filesystem abstraction for pollable objects Davi Arnaut
2007-05-02  5:22 ` [patch 01/22] pollfs: kernel-side API header Davi Arnaut
2007-05-02  5:22 ` [patch 02/22] pollfs: file system operations Davi Arnaut
2007-05-02  5:22 ` [patch 03/22] pollfs: asynchronously wait for a signal Davi Arnaut
2007-05-02  5:22 ` [patch 04/22] pollfs: pollable signal Davi Arnaut
2007-05-02  5:22 ` [patch 05/22] pollfs: pollable signal compat code Davi Arnaut
2007-05-02  5:22 ` [patch 06/22] pollfs: export the plsignal system call Davi Arnaut
2007-05-02  5:22 ` [patch 07/22] pollfs: x86, wire up " Davi Arnaut
2007-05-02  5:22 ` [patch 08/22] pollfs: x86_64, " Davi Arnaut
2007-05-02  5:22 ` [patch 09/22] pollfs: pollable hrtimers Davi Arnaut
2007-05-02 21:16   ` Thomas Gleixner
2007-05-02 23:00     ` Davi Arnaut
2007-05-02  5:22 ` [patch 10/22] pollfs: export the pltimer system call Davi Arnaut
2007-05-02  5:22 ` [patch 11/22] pollfs: x86, wire up " Davi Arnaut
2007-05-02  5:22 ` [patch 12/22] pollfs: x86_64, " Davi Arnaut
2007-05-02  5:22 ` [patch 13/22] pollfs: asynchronous futex wait Davi Arnaut
2007-05-02  5:22 ` [patch 14/22] pollfs: pollable futex Davi Arnaut
2007-05-02  5:54   ` Eric Dumazet
2007-05-02  6:16     ` Davi Arnaut
2007-05-02  6:39       ` Eric Dumazet
2007-05-02  6:54         ` Davi Arnaut
2007-05-02  7:11         ` Davi Arnaut
2007-05-02  7:40   ` Ulrich Drepper
2007-05-02  7:55     ` Eric Dumazet
2007-05-02  8:08       ` Ulrich Drepper
2007-05-02  8:49         ` Eric Dumazet
2007-05-02 16:39           ` Ulrich Drepper
2007-05-02 16:59             ` Davi Arnaut
2007-05-02 17:10               ` Ulrich Drepper
2007-05-02 17:29                 ` Davide Libenzi
2007-05-02 17:53                   ` Ulrich Drepper
2007-05-02 18:21                     ` Davide Libenzi
2007-05-03 13:46                       ` Ulrich Drepper
2007-05-03 18:24                         ` Davide Libenzi
2007-05-03 19:03                           ` Ulrich Drepper
2007-05-03 22:14                             ` Davide Libenzi
2007-05-04 15:28                               ` Ulrich Drepper
2007-05-04 19:15                                 ` Davide Libenzi
2007-05-04 19:20                                   ` 2.6.20.4 / 2.6.21.1 AT91SAM9260-EK oops Ryan Ordway
2007-05-04 23:38                                   ` Ulrich Drepper [this message]
2007-05-05 18:54                                     ` [patch 14/22] pollfs: pollable futex Davide Libenzi
2007-05-06  7:50                                       ` Ulrich Drepper
2007-05-06 19:47                                         ` Davide Libenzi
2007-05-06 19:54                                         ` Andrew Morton
2007-05-06 20:18                                           ` Davide Libenzi
2007-05-06 21:57                                           ` Davi Arnaut
2007-05-07  5:33                                           ` Ulrich Drepper
2007-05-07  5:46                                           ` Ulrich Drepper
2007-05-02 17:37                 ` Davi Arnaut
2007-05-02 17:49                   ` Ulrich Drepper
2007-05-02 18:05                     ` Davi Arnaut
2007-05-03 13:40                       ` Ulrich Drepper
2007-05-02 12:20     ` Davi Arnaut
2007-05-02 12:39     ` Davi Arnaut
2007-05-02 16:46       ` Ulrich Drepper
2007-05-02 17:05         ` Davi Arnaut
2007-05-02  5:22 ` [patch 15/22] pollfs: export the plfutex system call Davi Arnaut
2007-05-02  5:22 ` [patch 16/22] pollfs: x86, wire up " Davi Arnaut
2007-05-02  5:22 ` [patch 17/22] pollfs: x86_64, " Davi Arnaut
2007-05-02  5:22 ` [patch 18/22] pollfs: check if a AIO event ring is empty Davi Arnaut
2007-05-02  5:22 ` [patch 19/22] pollfs: pollable aio Davi Arnaut
2007-05-02  5:22 ` [patch 20/22] pollfs: export the plaio system call Davi Arnaut
2007-05-02  5:22 ` [patch 21/22] pollfs: x86, wire up " Davi Arnaut
2007-05-02  5:22 ` [patch 22/22] pollfs: x86_64, " Davi Arnaut
2007-05-02  6:05 ` [patch 00/22] pollfs: filesystem abstraction for pollable objects Andrew Morton
2007-05-02 17:28   ` Davide Libenzi
2007-05-02 17:47     ` Davi Arnaut
2007-05-02 18:23       ` Davide Libenzi
2007-05-02 18:50         ` Davi Arnaut
2007-05-02 19:42           ` Davide Libenzi
2007-05-02 20:11             ` Davi Arnaut

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=a36005b50705041638h37cd0654q442e7d50f1e63040@mail.gmail.com \
    --to=drepper@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=dada1@cosmosbay.com \
    --cc=davi@haxent.com.br \
    --cc=davidel@xmailserver.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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®