class DistributedObject
def method
Thread.pass while sem.try_lock
yield
ensure
sem.unlock
^^^
Where is this getting locked?
from the pickaxe :
try_lock : ref.try_lock → true or false
Attempts to obtain the lock and
returns immediately. Returns true if
the lock was granted.
so the thread yield control until the lock is granted.
ah-ha! You really want #synchronize, it does the waiting for you, and
its not a busy-wait.
class DistributedObject
def method
sem.synchronize { yield }
end
end
(I hadn’t realized that try_lock worked this way, I thought it just told
you if the lock was available or not… learn something new every day 
You could install a signal handler that would unlock the Mutex, but I’m
not sure how much work would be involved to make it always do the right
thing, as you need to know that you locked it and not some other
client (this may or may not be a problem)
this is not possible for the reasons you mention.
Why are you getting the sigabrt, anyway?
because i am doing a ‘ctrl-c’ from the client tty. i am trying to make my
class super bomber. with this exception - it seems to be.
in general, i am trying to learn what happens in a drb server when a client
aborts or is otherwise terminated prematurely (eg. before the method has
finished completing)
For one, I’d push the lock as deep as you can get it, no sense locking
when you’re not doing something that needs to update protected state
(say, reading or writing a file, calculating statistics, etc.).
As for the real problem here, I’ll defer to the rest of the crowd, I
don’t feel experienced enough to give such advice
···
ahoward (ahoward@fsl.noaa.gov) wrote:
On Sat, 8 Feb 2003, Eric Hodel wrote:
–
Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
