On Saturday 06 August 2005 18:02, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Hans Petter Selasky
writes:
> >Yes, you are right, but the problem is, that for most callback systems in
> > the kernel, there is no mechanism that will pre-lock some custom mutex
> > before calling the callback.
In message <[EMAIL PROTECTED]>, Hans Petter Selasky writes:
>Yes, you are right, but the problem is, that for most callback systems in the
>kernel, there is no mechanism that will pre-lock some custom mutex before
>calling the callback.
>
>I am not speaking about adding lines to existing code, bu
Hans Petter Selasky wrote:
On Friday 05 August 2005 19:29, John Baldwin wrote:
Yes, you are right, but the problem is, that for most callback systems in the
kernel, there is no mechanism that will pre-lock some custom mutex before
calling the callback.
Not generally applicable to this ca
On Friday 05 August 2005 19:29, John Baldwin wrote:
> On Thursday 04 August 2005 04:53 pm, Hans Petter Selasky wrote:
> > On Thursday 04 August 2005 20:15, John Baldwin wrote:
> > > On Thursday 04 August 2005 12:50 pm, Hans Petter Selasky wrote:
> > > > On Thursday 04 August 2005 15:53, John Baldwi
In message: <[EMAIL PROTECTED]>
John Baldwin <[EMAIL PROTECTED]> writes:
: Maybe, but another thing you need to consider is "maintainenance" overhead.
: Device drivers, especially, should be the simplest parts of the kernel to
: implement because we want to minimize the potential for
On Thursday 04 August 2005 04:53 pm, Hans Petter Selasky wrote:
> On Thursday 04 August 2005 20:15, John Baldwin wrote:
> > On Thursday 04 August 2005 12:50 pm, Hans Petter Selasky wrote:
> > > On Thursday 04 August 2005 15:53, John Baldwin wrote:
> > > > On Thursday 04 August 2005 07:40 am, Hans P
On Thursday 04 August 2005 20:15, John Baldwin wrote:
> On Thursday 04 August 2005 12:50 pm, Hans Petter Selasky wrote:
> > On Thursday 04 August 2005 15:53, John Baldwin wrote:
> > > On Thursday 04 August 2005 07:40 am, Hans Petter Selasky wrote:
> > > > On Wednesday 03 August 2005 19:21, John Bal
On Thu, Aug 04, 2005 at 06:50:12PM +0200, Hans Petter Selasky wrote:
> 2) nonblocking: increment some other refcount that the
>callback checks before accessing any data.
I think people usually call this something like a "generation count".
This sort of scheme used to be used for vnodes in Free
On Thursday 04 August 2005 12:50 pm, Hans Petter Selasky wrote:
> On Thursday 04 August 2005 15:53, John Baldwin wrote:
> > On Thursday 04 August 2005 07:40 am, Hans Petter Selasky wrote:
> > > On Wednesday 03 August 2005 19:21, John Baldwin wrote:
> > > > On Tuesday 02 August 2005 06:23 pm, Hans P
On Thursday 04 August 2005 15:53, John Baldwin wrote:
> On Thursday 04 August 2005 07:40 am, Hans Petter Selasky wrote:
> > On Wednesday 03 August 2005 19:21, John Baldwin wrote:
> > > On Tuesday 02 August 2005 06:23 pm, Hans Petter Selasky wrote:
> > > > Hi,
> > > >
> > > > I am looking for a safe
On Thursday 04 August 2005 14:08, Max Laier wrote:
> On Thursday 04 August 2005 13:40, Hans Petter Selasky wrote:
> > This is a copy and paste from the kernel sources:
> >
> > struct ucred *
> > crhold(struct ucred *cr)
> > {
> > The problem is, what happens if the kernel switches thread right here
On Thursday 04 August 2005 07:40 am, Hans Petter Selasky wrote:
> On Wednesday 03 August 2005 19:21, John Baldwin wrote:
> > On Tuesday 02 August 2005 06:23 pm, Hans Petter Selasky wrote:
> > > Hi,
> > >
> > > I am looking for a safe way to access structures that can be freed. The
> > > solution I
On Thursday 04 August 2005 13:40, Hans Petter Selasky wrote:
> This is a copy and paste from the kernel sources:
>
> struct ucred *
> crhold(struct ucred *cr)
> {
> The problem is, what happens if the kernel switches thread right here, and
> then the other thread calls "crfree()" on this structure,
On Wednesday 03 August 2005 19:21, John Baldwin wrote:
> On Tuesday 02 August 2005 06:23 pm, Hans Petter Selasky wrote:
> > Hi,
> >
> > I am looking for a safe way to access structures that can be freed. The
> > solution I am looking for must not:
> >
> > - hinder scaleability
> > - lead to use of
On Tuesday 02 August 2005 06:23 pm, Hans Petter Selasky wrote:
> Hi,
>
> I am looking for a safe way to access structures that can be freed. The
> solution I am looking for must not:
>
> - hinder scaleability
> - lead to use of a single lock
> - lead to lock order reversal
These aren't a very clea
Hi,
I am looking for a safe way to access structures that can be freed. The
solution I am looking for must not:
- hinder scaleability
- lead to use of a single lock
- lead to lock order reversal
Here is the solution I have landed on so far:
First I plan to make a reference count manager that
16 matches
Mail list logo
