Re: [RFC PATCH v2 00/13] Add futex2 syscall

Re: [RFC PATCH v2 00/13] Add futex2 syscall

[Stefan Metzmacher]

Hi André,
>  ** The wait on multiple problem
> 
>  The use case lies in the Wine implementation of the Windows NT interface
>  WaitMultipleObjects. This Windows API function allows a thread to sleep
>  waiting on the first of a set of event sources (mutexes, timers, signal,
>  console input, etc) to signal.  

With that in mind would it be good to have some interaction with epoll (and similar calls)?

Instead of having a blocked futex_waitv() waiting on an fd (maybe a generic eventfd() or a new futex2fd())
would be a better interface?

Or instead introduce an IORING_OP_FUTEX2_WAITV? Then the futex_waitv logic wait
in an io-wq kernel thread...

I guess the io_uring way would mean we could have that in mind as future addition, which can be implemented
later...

metze

Re: [RFC PATCH v2 00/13] Add futex2 syscall

[Daurnimator]

On Sun, 7 Mar 2021 at 22:35, Stefan Metzmacher <metze@samba.org> wrote:
> Instead of having a blocked futex_waitv() waiting on an fd (maybe a generic eventfd() or a new futex2fd())
> would be a better interface?

Like bring back FUTEX_FD? (which was removed back in 2.6.25)

Re: [RFC PATCH v2 00/13] Add futex2 syscall

[Stefan Metzmacher]

Am 07.03.21 um 12:56 schrieb Daurnimator:
> On Sun, 7 Mar 2021 at 22:35, Stefan Metzmacher <metze@samba.org> wrote:
>> Instead of having a blocked futex_waitv() waiting on an fd (maybe a generic eventfd() or a new futex2fd())
>> would be a better interface?
> 
> Like bring back FUTEX_FD? (which was removed back in 2.6.25)

Ah, ok, yes something like that.

But as that was removed because of races, but might not be a good idea to bring it back.

metze

RE: [RFC PATCH v2 00/13] Add futex2 syscall

[David Laight]

From: Stefan Metzmacher
> Sent: 07 March 2021 11:35
> 
> Hi André,
> >  ** The wait on multiple problem
> >
> >  The use case lies in the Wine implementation of the Windows NT interface
> >  WaitMultipleObjects. This Windows API function allows a thread to sleep
> >  waiting on the first of a set of event sources (mutexes, timers, signal,
> >  console input, etc) to signal.

They are all events.
You can only wait on either events or sockets (using select).
There is a socket api to signal an event when data arrives (etc).
There is also the insane (these days) restriction of 64 events.

> With that in mind would it be good to have some interaction with epoll (and similar calls)?

Or hook something up so that pollwakeup can kick a futex as well
as waking up poll() and adding an event to epoll().

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: [RFC PATCH v2 00/13] Add futex2 syscall

[Stefan Metzmacher]

Am 08.03.21 um 12:11 schrieb David Laight:
> From: Stefan Metzmacher
>> Sent: 07 March 2021 11:35
>>
>> Hi André,
>>>  ** The wait on multiple problem
>>>
>>>  The use case lies in the Wine implementation of the Windows NT interface
>>>  WaitMultipleObjects. This Windows API function allows a thread to sleep
>>>  waiting on the first of a set of event sources (mutexes, timers, signal,
>>>  console input, etc) to signal.
> 
> They are all events.
> You can only wait on either events or sockets (using select).
> There is a socket api to signal an event when data arrives (etc).
> There is also the insane (these days) restriction of 64 events.

Ok.

>> With that in mind would it be good to have some interaction with epoll (and similar calls)?
> 
> Or hook something up so that pollwakeup can kick a futex as well
> as waking up poll() and adding an event to epoll().

I guess as FUTEX_FD was already there and was removed we can stop this discussion.

If there will every be the need to an async call, I guess a io_uring based one would
be the best...

metze