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 t
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 fr
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) wrote
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 Gleix
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 AM
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
regard
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, T
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.
>
> Whic
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 wrote:
> > > On Thu, 15 M
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 lov
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 FUTEX_CLOCK_REALTIME
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 FUTEX
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 i
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, be
17 matches
Mail list logo
