bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] libpager/data-request.c: missing call to _pager_allow_termin


From: Neal H. Walfield
Subject: Re: [PATCH] libpager/data-request.c: missing call to _pager_allow_termination
Date: Tue, 28 Sep 2004 17:08:15 +0100
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Tue, 28 Sep 2004 18:33:57 +0300,
Ognyan Kulev wrote:
> 
> Neal H. Walfield wrote:
> > This looks correct to me.  Normally, I would say that this sort of
> > micro-optimization does not matter as we don't care how slow the error
> > path is, however, the other jump to allow_term_out (on the fast path)
> > also has a gratuitous unlock relock sequence:
> > 
> >   /* Let someone else in.  */
> >   _pager_release_seqno (p, seqno);
> >   mutex_unlock (&p->interlock);
> > 
> >   if (!doread)
> >     goto allow_term_out;
> > 
> > So, if wold be useful to also move the if above the unlock and moved
> > the mutex_lock in allow_term_out to error_read and adjusted callers.
> 
> Does this apply to goto error_read too?

No.  The error_read assumes that the interlock is held and that is the
correct assumption for all of the callers (and therefore no fix up is
required).

>   Actually, I haven't though that 
> unlock-relock is a problem here.

An unlock followed by a relock is just gratuitous.  In the fast path
we want to avoid them.

> >>    err = _pager_pagemap_resize (p, offset + length);
> >>    if (err)
> >>-    goto release_out;              /* Can't do much about the actual 
> >>error.  */
> >>+    {
> >>+      _pager_allow_termination (p);
> >>+      goto release_out;      /* Can't do much about the actual error.  */
> >>+    }
> > 
> > This only solves half the problem.  You also have to call
> > _pager_release_seqno as well.
> 
> It's called in release_out.

You're right, sorry.  (It is not called in allow_term_out which is
what I now remembering looking at.)

> > 2004-09-28  Neal H. Walfield  <neal@cs.uml.edu>
> >     Ognyan Kulev  <ogi@fmi.uni-sofia.bg>
> 
> I'm not sure this style is correct.

Something similar to this has been used in glibc for collaboration:

    2004-01-02  Jakub Jelinek  <jakub@redhat.com>
                Paolo Bonzini  <bonzini@gnu.org>
    
            * posix/regex_internal.h (re_const_bitset_ptr_t): New type.
            ...

Thanks,
Neal





reply via email to

[Prev in Thread] Current Thread [Next in Thread]