... 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
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
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 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 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 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 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 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 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
... 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 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
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 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
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
14 matches
Mail list logo