I'd like feedback on the attached patch, which adds support to our
time_pps_fetch() implementation for the blocking behaviors described in
section 3.4.3 of RFC 2783. The existing implementation can only return
the most recently captured data without blocking. These changes add the
ability to bloc
On Tue, Feb 05, 2013 at 09:41:38PM -0700, Ian Lepore wrote:
> I'd like feedback on the attached patch, which adds support to our
> time_pps_fetch() implementation for the blocking behaviors described in
> section 3.4.3 of RFC 2783. The existing implementation can only return
> the most recently ca
On Wed, 2013-02-06 at 17:58 +0200, Konstantin Belousov wrote:
> On Tue, Feb 05, 2013 at 09:41:38PM -0700, Ian Lepore wrote:
> > I'd like feedback on the attached patch, which adds support to our
> > time_pps_fetch() implementation for the blocking behaviors described in
> > section 3.4.3 of RFC 278
On Wed, Feb 06, 2013 at 05:58:30PM +0200, Konstantin Belousov wrote:
> On Tue, Feb 05, 2013 at 09:41:38PM -0700, Ian Lepore wrote:
> > I'd like feedback on the attached patch, which adds support to our
> > time_pps_fetch() implementation for the blocking behaviors described in
> > section 3.4.3 of
... why aren't you using atomics? or read/write barriers?
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
On Sat, Feb 09, 2013 at 02:47:06PM +0100, Jilles Tjoelker wrote:
> On Wed, Feb 06, 2013 at 05:58:30PM +0200, Konstantin Belousov wrote:
> > On Tue, Feb 05, 2013 at 09:41:38PM -0700, Ian Lepore wrote:
> > > I'd like feedback on the attached patch, which adds support to our
> > > time_pps_fetch() imp
On Fri, Feb 08, 2013 at 04:13:40PM -0700, Ian Lepore wrote:
> On Wed, 2013-02-06 at 17:58 +0200, Konstantin Belousov wrote:
> > On Tue, Feb 05, 2013 at 09:41:38PM -0700, Ian Lepore wrote:
> > > I'd like feedback on the attached patch, which adds support to our
> > > time_pps_fetch() implementation
On Sun, 2013-02-10 at 12:41 +0200, Konstantin Belousov wrote:
> On Fri, Feb 08, 2013 at 04:13:40PM -0700, Ian Lepore wrote:
> > On Wed, 2013-02-06 at 17:58 +0200, Konstantin Belousov wrote:
> > > On Tue, Feb 05, 2013 at 09:41:38PM -0700, Ian Lepore wrote:
> > > > I'd like feedback on the attached p
On Sun, 2013-02-10 at 12:37 +0200, Konstantin Belousov wrote:
> On Sat, Feb 09, 2013 at 02:47:06PM +0100, Jilles Tjoelker wrote:
> > On Wed, Feb 06, 2013 at 05:58:30PM +0200, Konstantin Belousov wrote:
> > > On Tue, Feb 05, 2013 at 09:41:38PM -0700, Ian Lepore wrote:
> > > > I'd like feedback on th
On 12 February 2013 08:03, Ian Lepore wrote:
>> I agree that for practical means, the _currently_ used compilers should
>> consider the tsleep() call as the sequential point. But then the volatile
>> qualifier cast applied for the given access would not change the code as
>> well.
>>
>
> Doesn't
On Tue, Feb 12, 2013 at 09:03:39AM -0700, Ian Lepore wrote:
> On Sun, 2013-02-10 at 12:37 +0200, Konstantin Belousov wrote:
> > On Sat, Feb 09, 2013 at 02:47:06PM +0100, Jilles Tjoelker wrote:
> > > On Wed, Feb 06, 2013 at 05:58:30PM +0200, Konstantin Belousov wrote:
> > > > On Tue, Feb 05, 2013 at
On Tue, 2013-02-12 at 22:34 +0200, Konstantin Belousov wrote:
> On Tue, Feb 12, 2013 at 09:03:39AM -0700, Ian Lepore wrote:
> > On Sun, 2013-02-10 at 12:37 +0200, Konstantin Belousov wrote:
> > > On Sat, Feb 09, 2013 at 02:47:06PM +0100, Jilles Tjoelker wrote:
> > > > On Wed, Feb 06, 2013 at 05:58:
On Wed, Feb 13, 2013 at 08:16:32AM -0700, Ian Lepore wrote:
> On Tue, 2013-02-12 at 22:34 +0200, Konstantin Belousov wrote:
> > On Tue, Feb 12, 2013 at 09:03:39AM -0700, Ian Lepore wrote:
> > > On Sun, 2013-02-10 at 12:37 +0200, Konstantin Belousov wrote:
> > > > On Sat, Feb 09, 2013 at 02:47:06PM
... why don't we just mark tsleep() as a barrier point and be done with it?
Same as the wakeup call?
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebs
14 matches
Mail list logo