Re: [PATCH] Futex Generalization Patch

[Hubertus Franke]

On Wednesday 10 April 2002 12:37 pm, Rusty Russell wrote:
> In message <[e-mail]> 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  ([e-mail])