At 1:16 PM -0500 7/28/99, 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.
Is the timeout the amount of time you want to wait to see if you
can get the lock? It's not the duration for which the lock is in
force.
--
Paul DuBois, paul@stripped
