On Sun, Aug 31, 2014 at 6:23 PM, Ryota Ozaki ozak...@netbsd.org wrote:
Hi darrenr and rmind,
Thank you for your replying, and I'm sorry for not replying yet.
I'm now in a busy period for several weeks. I'll be back at the
next weekend.
I'm back finally. I needed one more month than I
On Tue, Aug 26, 2014 at 4:49 AM, Mindaugas Rasiukevicius
rm...@netbsd.org wrote:
Ryota Ozaki ozak...@netbsd.org wrote:
Hi,
I thought I need more experience of pserialize
(and lock primitives) to tackle ifnet work.
So I suspended the work and now I am trying
another easier task, bpf.
On Sat, Aug 9, 2014 at 8:26 PM, Darren Reed darr...@netbsd.org wrote:
On 7/08/2014 7:49 PM, Ryota Ozaki wrote:
Hi,
I thought I need more experience of pserialize
(and lock primitives) to tackle ifnet work.
So I suspended the work and now I am trying
another easier task, bpf.
Ryota Ozaki ozak...@netbsd.org wrote:
Hi,
I thought I need more experience of pserialize
(and lock primitives) to tackle ifnet work.
So I suspended the work and now I am trying
another easier task, bpf.
http://www.netbsd.org/~ozaki-r/mpsafe-bpf.diff
As Darren mentioned - there are
Darren Reed darr...@netbsd.org wrote:
Looking at the use of pserialze functions, you've got a single
data structure (bpf_iflist) that is at some times covered by
bpf_iflist_mtx and others not. That's a bad design. Ideally the
data structure should only be covered by one locking mechanism
so
Looking at the use of pserialze functions, you've got a single
data structure (bpf_iflist) that is at some times covered by
bpf_iflist_mtx and others not. That's a bad design. Ideally the
data structure should only be covered by one locking mechanism
so you need to choose whether it is pserialize
On 7/08/2014 7:49 PM, Ryota Ozaki wrote:
Hi,
I thought I need more experience of pserialize
(and lock primitives) to tackle ifnet work.
So I suspended the work and now I am trying
another easier task, bpf.
http://www.netbsd.org/~ozaki-r/mpsafe-bpf.diff
This code has race conditions built
On 2014-08-07 11:57, Greg Troxel wrote:
I realize it's typical to reject adding such comments on the theory
that
everyone should already understand all of this. But the complexity of
our locking (and memory allocation) is high, and I think it helps
correctness to be much more explicit about
Hi,
I thought I need more experience of pserialize
(and lock primitives) to tackle ifnet work.
So I suspended the work and now I am trying
another easier task, bpf.
http://www.netbsd.org/~ozaki-r/mpsafe-bpf.diff
I add a spin mutex to both struct bpf_d and
bpf_if to protect them. And also a pair
Ryota Ozaki ozak...@netbsd.org writes:
BTW, I worry about there is no easy way to
know if a function in a critical section
blocks/sleeps or not. So I wrote a patch to
detect that: http://www.netbsd.org/~ozaki-r/debug-pserialize.diff
Is it meaningful?
It seems sensible, but it is very much
On Thu, Aug 7, 2014 at 7:57 PM, Greg Troxel g...@ir.bbn.com wrote:
Ryota Ozaki ozak...@netbsd.org writes:
BTW, I worry about there is no easy way to
know if a function in a critical section
blocks/sleeps or not. So I wrote a patch to
detect that:
On Thu, Aug 7, 2014 at 8:48 PM, Ryota Ozaki ozak...@netbsd.org wrote:
On Thu, Aug 7, 2014 at 7:57 PM, Greg Troxel g...@ir.bbn.com wrote:
Ryota Ozaki ozak...@netbsd.org writes:
BTW, I worry about there is no easy way to
know if a function in a critical section
blocks/sleeps or not. So I
12 matches
Mail list logo
