lkml.org 
[lkml]   [2002]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Futex Generalization Patch
Date
On Wednesday 10 April 2002 12:37 pm, Rusty Russell wrote:
> In message <20020410152354.169FF3FE06@smtp.linux.ibm.com> you write:
> > Enclosed is an "asynchronous" extension to futexes.
>
> Wow... I never thought of that. Cool!
>
> My main concern is the DoS of multiple kmallocs. Alan Cox suggested
> tying it to an fd (ie. naturally limited), and I think this might work
> (I don't know much about async io). ie. (int)utime is the fd to wake
> up, and then it can be used for async io OR a poll/select interface
> using existing infrastructure.
>
> Probably it has to be a special fd (/dev/futex?).
>
> Thoughts?
> Rusty.

Is the idea to write one's own poll/select routine for the /dev/futex files?

Dependent on the circumstance:
(A) you want to globally limit the number of outstanding waits !

Why so complicated, (assuming I understand the suggestion above) ?

Simply have a /proc/futex subsystem that tell's you how many outstanding
awaits can be active at any time.
kmalloc() becomes if (fq_count++ > LIMIT) return -EAGAIN;
kfree() becomes kfree() ; fq_count--;

(B)
if you really want per process limits, then ofcourse, you need something
different than my suggestions under (A)

We allocate a file structure with private data for opening /dev/futex !
We associate that file descriptor
(a) a counter (reflecting the number of outstanding futex_q)
(b) a notify_queue

(a) is limited by a per FD limit of outstanding futex_q (still need a
global limit here)
(b) solves the __exit_futex() problem.
We wouldn't need that call, as the pending notifications will be deleted with
the FD destruction... cool...

Can somebody in the thread world weight in what there preferred mechanism is
regarding limits etc. Do you need to control the issue on how the signal is
delivered? Is a file descriptor good enough or you want a sys_call interface ?

All this is merely a "clean/usefull interface" issue (other then the DoS).

One other idea here ...



Can you sketch out the file design and I code it up.


We need this async functionality for M:N threads and we need it soon.
--
-- Hubertus Franke (frankeh@watson.ibm.com)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:25    [W:0.037 / U:2.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site