List:General Discussion« Previous MessageNext Message »
From:Gerald Clark Date:July 28 1999 6:31pm
Subject:Re: On GET_LOCK ()
View as plain text  
Jim Faucette wrote:
> 
> Paul DuBois wrote:
> >
> > At 8:48 AM -0500 7/28/99, <sinisa@stripped> wrote:
> > >Benjamin Pflugmann writes:
> > > > Hi.
> > > >
> > > > > What do you think that I suggest to Monty that we add a NON_WAIT
> > > > > option to the get_lock, which would not hang, but would return 0
> if a
> > > > > lock is struck. In that case, a programmer could check the return
> code
> > > > > and inform the user that a resource is unavailable .....
> > > >
> > > > Either I totally misunderstand you or you are talking about
> > > > GET_LOCK('foo',0), which is already available and will return 0 in
> > > > case of an existing lock...?
> > > >
> > > > Bye,
> > > >
> > > >         Benjamin.
> > > >
> > >
> > >Yes, you are partially right.
> > >
> > >'0' is returned when lock has passed it's timeout, which in case of
> > >'0' means always.
> >
> > Are you saying the GET_LOCK() call will fail to obtain the lock i
> > you specify a timeout value of 0?  That isn't so.  If the lock is
> > available, GET_LOCK() will succeed.  If not, GET_LOCK() will return
> > 0.  In both cases it returns immediately.  It seems to me this is
> > a perfectly adequate way of "polling" for a lock.
> >
> > >
> > >No, there should be then some other value, like '2' or '-1' for non
> > >wait locks
> >
> > I think I need to see an example of where this is needed.  I'm not
> > sure I understand why GET_LOCK(name,0) doesn't do what's required.
> >
> 
> Currently (3.22.20) GET_LOCK only works with persistent connections, so
> it wouldn't help simple web applications.
> 
> Also (at least on this version) a timeout isn't releasing the lock. It
> only releases on a RELEASE_LOCK or thread termination. It appears a 0
> parm sets a lock without a timeout. If this is the intended
> (undocumented) result then polling with 0 could work.
> 
> As for Paul's point: once you obtain a 1 and if you want a timeout you'd
> issue a 2nd call:
>  GET_LOCK(name, timeout_wanted);
> 
> An alternative to 2 calls would be to use a negative timeout to denote a
> non-wait request. If the lock is available the timeout would be set to
> the absolute of the timeout parm and return 1, else 0 would be
> immediately returned.
> 
>   jim...
> 
> ---------------------------------------------------------------------
The timeout for get_lock() does not time-out the lock.
it only times-out the attempt to get the lock.
Once the lock is obtained, it is forever unless your connection
is closed, or another get_lock() or release_lock() call is made.
At least that is how it has always worked my my machine. I am currently
running 3.22.24.
Thread
Restrict Accesstoxalot27 Jul
  • Restrict Accesssinisa27 Jul
    • Re: Restrict AccessThimble Smith27 Jul
      • Re: Restrict AccessPaul DuBois27 Jul
        • Re: Restrict AccessMartin Ramsch27 Jul
          • Re: Restrict AccessPaul DuBois28 Jul
            • Re: Restrict AccessThimble Smith28 Jul
        • Re: Restrict Accesssinisa28 Jul
    • Re: Restrict Accesstoxalot28 Jul
      • On GET_LOCK ()sinisa28 Jul
        • Re: On GET_LOCK ()Benjamin Pflugmann28 Jul
          • Re: On GET_LOCK ()sinisa28 Jul
            • Re: On GET_LOCK ()Paul DuBois28 Jul
          • Re: On GET_LOCK ()Jim Faucette28 Jul
            • Re: On GET_LOCK ()Paul DuBois28 Jul
              • Re: On GET_LOCK ()Thimble Smith28 Jul
          • Re: On GET_LOCK ()Gerald Clark28 Jul
        • Re: On GET_LOCK ()Paul DuBois28 Jul
          • Re: On GET_LOCK ()sinisa28 Jul
            • Re: On GET_LOCK ()Paul DuBois28 Jul
  • Re: On GET_LOCK ()Scott Hess28 Jul
    • getting rid of duplicatesJoel Bremson28 Jul
    • Re: getting rid of duplicatesChristian Mack28 Jul
    • Re: On GET_LOCK ()sinisa29 Jul
      • Re: On GET_LOCK ()Paul DuBois29 Jul
    • Re: On GET_LOCK ()Scott Hess29 Jul
Re: On GET_LOCK ()toxalot28 Jul
  • Re: On GET_LOCK ()sinisa28 Jul
    • Re: On GET_LOCK ()Benjamin Pflugmann29 Jul
  • Re: On GET_LOCK ()Sasha Pachev29 Jul
    • Re: On GET_LOCK ()Benjamin Pflugmann31 Jul
Re: On GET_LOCK ()Thimble Smith29 Jul
  • Re: On GET_LOCK ()Fraser MacKenzie29 Jul
    • Re: On GET_LOCK ()Thimble Smith29 Jul
      • Re: On GET_LOCK ()Fraser MacKenzie29 Jul
Re: On GET_LOCK()R. Mentink31 Jul