On Thu, 23 Jun 2016, Michael Kerrisk (man-pages) wrote:
> On 06/23/2016 08:28 PM, Darren Hart wrote:
> > And as a follow-on, what is the reason for FUTEX_LOCK_PI only using
> > CLOCK_REALTIME? It seems reasonable to me that a user may want to wait a
> > specific amount of time, regardless of wall
On Thu, 23 Jun 2016, Michael Kerrisk (man-pages) wrote:
> On 06/23/2016 08:28 PM, Darren Hart wrote:
> > And as a follow-on, what is the reason for FUTEX_LOCK_PI only using
> > CLOCK_REALTIME? It seems reasonable to me that a user may want to wait a
> > specific amount of time, regardless of wall
On 06/24/2016 11:52 AM, Thomas Gleixner wrote:
On Fri, 24 Jun 2016, Michael Kerrisk (man-pages) wrote:
By the way, I just realized something that wasn't initially obvious
to me, and documented it in the futex(2) man page:
Note: for FUTEX_WAIT, timeout is interpreted as a
On 06/24/2016 11:52 AM, Thomas Gleixner wrote:
On Fri, 24 Jun 2016, Michael Kerrisk (man-pages) wrote:
By the way, I just realized something that wasn't initially obvious
to me, and documented it in the futex(2) man page:
Note: for FUTEX_WAIT, timeout is interpreted as a
On Fri, 24 Jun 2016, Michael Kerrisk (man-pages) wrote:
> By the way, I just realized something that wasn't initially obvious
> to me, and documented it in the futex(2) man page:
>
> Note: for FUTEX_WAIT, timeout is interpreted as a
> relative value. This differs
On Fri, 24 Jun 2016, Michael Kerrisk (man-pages) wrote:
> By the way, I just realized something that wasn't initially obvious
> to me, and documented it in the futex(2) man page:
>
> Note: for FUTEX_WAIT, timeout is interpreted as a
> relative value. This differs
On 06/23/2016 09:53 PM, Darren Hart wrote:
On Thu, Jun 23, 2016 at 08:35:15PM +0200, Michael Kerrisk (man-pages) wrote:
Hi Darren,
On 06/23/2016 06:16 PM, Darren Hart wrote:
On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote:
On Thu, 23 Jun 2016, Michael Kerrisk (man-pages)
On 06/23/2016 09:53 PM, Darren Hart wrote:
On Thu, Jun 23, 2016 at 08:35:15PM +0200, Michael Kerrisk (man-pages) wrote:
Hi Darren,
On 06/23/2016 06:16 PM, Darren Hart wrote:
On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote:
On Thu, 23 Jun 2016, Michael Kerrisk (man-pages)
On Thu, Jun 23, 2016 at 12:55:15PM -0700, Darren Hart wrote:
> On Thu, Jun 23, 2016 at 08:41:09PM +0200, Michael Kerrisk (man-pages) wrote:
> > On 06/23/2016 08:28 PM, Darren Hart wrote:
> > > On Thu, Jun 23, 2016 at 07:26:52PM +0200, Thomas Gleixner wrote:
> > > > On Thu, 23 Jun 2016, Darren Hart
On Thu, Jun 23, 2016 at 12:55:15PM -0700, Darren Hart wrote:
> On Thu, Jun 23, 2016 at 08:41:09PM +0200, Michael Kerrisk (man-pages) wrote:
> > On 06/23/2016 08:28 PM, Darren Hart wrote:
> > > On Thu, Jun 23, 2016 at 07:26:52PM +0200, Thomas Gleixner wrote:
> > > > On Thu, 23 Jun 2016, Darren Hart
On Thu, Jun 23, 2016 at 08:41:09PM +0200, Michael Kerrisk (man-pages) wrote:
> On 06/23/2016 08:28 PM, Darren Hart wrote:
> > On Thu, Jun 23, 2016 at 07:26:52PM +0200, Thomas Gleixner wrote:
> > > On Thu, 23 Jun 2016, Darren Hart wrote:
> > > > On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas
On Thu, Jun 23, 2016 at 08:41:09PM +0200, Michael Kerrisk (man-pages) wrote:
> On 06/23/2016 08:28 PM, Darren Hart wrote:
> > On Thu, Jun 23, 2016 at 07:26:52PM +0200, Thomas Gleixner wrote:
> > > On Thu, 23 Jun 2016, Darren Hart wrote:
> > > > On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas
On Thu, Jun 23, 2016 at 08:35:15PM +0200, Michael Kerrisk (man-pages) wrote:
> Hi Darren,
>
> On 06/23/2016 06:16 PM, Darren Hart wrote:
> > On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote:
> > > On Thu, 23 Jun 2016, Michael Kerrisk (man-pages) wrote:
> > > > On 06/23/2016 09:18
On Thu, Jun 23, 2016 at 08:35:15PM +0200, Michael Kerrisk (man-pages) wrote:
> Hi Darren,
>
> On 06/23/2016 06:16 PM, Darren Hart wrote:
> > On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote:
> > > On Thu, 23 Jun 2016, Michael Kerrisk (man-pages) wrote:
> > > > On 06/23/2016 09:18
On 06/23/2016 08:28 PM, Darren Hart wrote:
On Thu, Jun 23, 2016 at 07:26:52PM +0200, Thomas Gleixner wrote:
On Thu, 23 Jun 2016, Darren Hart wrote:
On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote:
In my opinion, we should treat the timeout value as relative for FUTEX_WAIT
On 06/23/2016 08:28 PM, Darren Hart wrote:
On Thu, Jun 23, 2016 at 07:26:52PM +0200, Thomas Gleixner wrote:
On Thu, 23 Jun 2016, Darren Hart wrote:
On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote:
In my opinion, we should treat the timeout value as relative for FUTEX_WAIT
Hi Darren,
On 06/23/2016 06:16 PM, Darren Hart wrote:
On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote:
On Thu, 23 Jun 2016, Michael Kerrisk (man-pages) wrote:
On 06/23/2016 09:18 AM, Thomas Gleixner wrote:
Once upon a time, you told me the following:
On 15 May 2014 at 16:14,
Hi Darren,
On 06/23/2016 06:16 PM, Darren Hart wrote:
On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote:
On Thu, 23 Jun 2016, Michael Kerrisk (man-pages) wrote:
On 06/23/2016 09:18 AM, Thomas Gleixner wrote:
Once upon a time, you told me the following:
On 15 May 2014 at 16:14,
On Thu, Jun 23, 2016 at 07:26:52PM +0200, Thomas Gleixner wrote:
> On Thu, 23 Jun 2016, Darren Hart wrote:
> > On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote:
> > In my opinion, we should treat the timeout value as relative for FUTEX_WAIT
> > regardless of the CLOCK used.
>
>
On Thu, Jun 23, 2016 at 07:26:52PM +0200, Thomas Gleixner wrote:
> On Thu, 23 Jun 2016, Darren Hart wrote:
> > On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote:
> > In my opinion, we should treat the timeout value as relative for FUTEX_WAIT
> > regardless of the CLOCK used.
>
>
On Thu, 23 Jun 2016, Darren Hart wrote:
> On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote:
> In my opinion, we should treat the timeout value as relative for FUTEX_WAIT
> regardless of the CLOCK used.
Which requires even more changes as you have to select which clock you are
using
On Thu, 23 Jun 2016, Darren Hart wrote:
> On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote:
> In my opinion, we should treat the timeout value as relative for FUTEX_WAIT
> regardless of the CLOCK used.
Which requires even more changes as you have to select which clock you are
using
On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote:
> On Thu, 23 Jun 2016, Michael Kerrisk (man-pages) wrote:
> > On 06/23/2016 09:18 AM, Thomas Gleixner wrote:
> > Once upon a time, you told me the following:
> >
> > On 15 May 2014 at 16:14, Thomas Gleixner
On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote:
> On Thu, 23 Jun 2016, Michael Kerrisk (man-pages) wrote:
> > On 06/23/2016 09:18 AM, Thomas Gleixner wrote:
> > Once upon a time, you told me the following:
> >
> > On 15 May 2014 at 16:14, Thomas Gleixner wrote:
> > > On Thu, 15
On Thu, 23 Jun 2016, Michael Kerrisk (man-pages) wrote:
> On 06/23/2016 09:18 AM, Thomas Gleixner wrote:
> Once upon a time, you told me the following:
>
> On 15 May 2014 at 16:14, Thomas Gleixner wrote:
> > On Thu, 15 May 2014, Michael Kerrisk (man-pages) wrote:
> > > And
On Thu, 23 Jun 2016, Michael Kerrisk (man-pages) wrote:
> On 06/23/2016 09:18 AM, Thomas Gleixner wrote:
> Once upon a time, you told me the following:
>
> On 15 May 2014 at 16:14, Thomas Gleixner wrote:
> > On Thu, 15 May 2014, Michael Kerrisk (man-pages) wrote:
> > > And that universe would
On 06/23/2016 09:18 AM, Thomas Gleixner wrote:
On Wed, 22 Jun 2016, Darren Hart wrote:
However, I don't think the patch below is correct. The existing logic
determines the type of timeout based on the futex_op when it should instead
determine the type of timeout based on the
Hi Darren,
On 06/23/2016 06:48 AM, Darren Hart wrote:
On Mon, Jun 20, 2016 at 04:26:52PM +0200, Matthieu CASTET wrote:
Hi,
the commit 337f13046ff03717a9e99675284a817527440a49 is saying that it
change to syscall to an equivalent to FUTEX_WAIT_BITSET |
FUTEX_CLOCK_REALTIME with a bitset of
On 06/23/2016 09:18 AM, Thomas Gleixner wrote:
On Wed, 22 Jun 2016, Darren Hart wrote:
However, I don't think the patch below is correct. The existing logic
determines the type of timeout based on the futex_op when it should instead
determine the type of timeout based on the
Hi Darren,
On 06/23/2016 06:48 AM, Darren Hart wrote:
On Mon, Jun 20, 2016 at 04:26:52PM +0200, Matthieu CASTET wrote:
Hi,
the commit 337f13046ff03717a9e99675284a817527440a49 is saying that it
change to syscall to an equivalent to FUTEX_WAIT_BITSET |
FUTEX_CLOCK_REALTIME with a bitset of
On Wed, 22 Jun 2016, Darren Hart wrote:
> However, I don't think the patch below is correct. The existing logic
> determines the type of timeout based on the futex_op when it should instead
> determine the type of timeout based on the FUTEX_CLOCK_REALTIME flag.
No.
> My reading of the man page
On Wed, 22 Jun 2016, Darren Hart wrote:
> However, I don't think the patch below is correct. The existing logic
> determines the type of timeout based on the futex_op when it should instead
> determine the type of timeout based on the FUTEX_CLOCK_REALTIME flag.
No.
> My reading of the man page
On Mon, Jun 20, 2016 at 04:26:52PM +0200, Matthieu CASTET wrote:
> Hi,
>
> the commit 337f13046ff03717a9e99675284a817527440a49 is saying that it
> change to syscall to an equivalent to FUTEX_WAIT_BITSET |
> FUTEX_CLOCK_REALTIME with a bitset of FUTEX_BITSET_MATCH_ANY.
>
> It seems wrong to me,
On Mon, Jun 20, 2016 at 04:26:52PM +0200, Matthieu CASTET wrote:
> Hi,
>
> the commit 337f13046ff03717a9e99675284a817527440a49 is saying that it
> change to syscall to an equivalent to FUTEX_WAIT_BITSET |
> FUTEX_CLOCK_REALTIME with a bitset of FUTEX_BITSET_MATCH_ANY.
>
> It seems wrong to me,
Hi,
the commit 337f13046ff03717a9e99675284a817527440a49 is saying that it
change to syscall to an equivalent to FUTEX_WAIT_BITSET |
FUTEX_CLOCK_REALTIME with a bitset of FUTEX_BITSET_MATCH_ANY.
It seems wrong to me, because in case of FUTEX_WAIT, in
"SYSCALL_DEFINE6(futex", we convert relative
Hi,
the commit 337f13046ff03717a9e99675284a817527440a49 is saying that it
change to syscall to an equivalent to FUTEX_WAIT_BITSET |
FUTEX_CLOCK_REALTIME with a bitset of FUTEX_BITSET_MATCH_ANY.
It seems wrong to me, because in case of FUTEX_WAIT, in
"SYSCALL_DEFINE6(futex", we convert relative
FUTEX_CLOCK_REALTIME with FUTEX_WAIT op
While reviewing Michael Kerrisk's recent futex manpage update, I noticed
that we allow the FUTEX_CLOCK_REALTIME flag for FUTEX_WAIT_BITSET but
not for FUTEX_WAIT.
FUTEX_WAIT is treated as a simple version for FUTEX_WAIT_BITSET
internally (with a bitmask
Sun, 20 Dec 2015 12:43:25 +0100
futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op
While reviewing Michael Kerrisk's recent futex manpage update, I noticed
that we allow the FUTEX_CLOCK_REALTIME flag for FUTEX_WAIT_BITSET but
not for FUTEX_WAIT.
FUTEX_WAIT is treated as a si
On Fri, 18 Dec 2015, Darren Hart wrote:
While reviewing Michael Kerrisk's recent futex manpage update, I noticed
that we allow the FUTEX_CLOCK_REALTIME flag for FUTEX_WAIT_BITSET but
not for FUTEX_WAIT.
FUTEX_WAIT is treated as a simple version for FUTEX_WAIT_BITSET
internally (with a bitmask
While reviewing Michael Kerrisk's recent futex manpage update, I noticed
that we allow the FUTEX_CLOCK_REALTIME flag for FUTEX_WAIT_BITSET but
not for FUTEX_WAIT.
FUTEX_WAIT is treated as a simple version for FUTEX_WAIT_BITSET
internally (with a bitmask of FUTEX_BITSET_MATCH_ANY). As such, I
On Fri, 18 Dec 2015, Darren Hart wrote:
While reviewing Michael Kerrisk's recent futex manpage update, I noticed
that we allow the FUTEX_CLOCK_REALTIME flag for FUTEX_WAIT_BITSET but
not for FUTEX_WAIT.
FUTEX_WAIT is treated as a simple version for FUTEX_WAIT_BITSET
internally (with a bitmask
While reviewing Michael Kerrisk's recent futex manpage update, I noticed
that we allow the FUTEX_CLOCK_REALTIME flag for FUTEX_WAIT_BITSET but
not for FUTEX_WAIT.
FUTEX_WAIT is treated as a simple version for FUTEX_WAIT_BITSET
internally (with a bitmask of FUTEX_BITSET_MATCH_ANY). As such, I
42 matches
Mail list logo