From: Robert Klemme <shortcutter@...>
Date: 2008-04-23T22:11:10+09:00
Subject: Re: Deadlock in DRb

2008/4/23, Lars Christensen <larsch@belunktum.dk>:
> On Apr 22, 3:45 pm, Robert Klemme <shortcut...@googlemail.com> wrote:
>  > 2008/4/22, Lars Christensen <lar...@belunktum.dk>:
>
>  > > In a program with two DRb servers running (two time start_service), i
>  >
>  > Why do you have two servers?
>
> Well... legacy. I have converted my application to having only 1 DRb
>  service started, but the same problem occurs. I still get a deadlock
>  after the clients have been connecting for a while.

Too bad.

>  > For adeadlockyou need at least two resources that are locked in
> > different order.  Maybe you have synchronized calls across the two
>  > servers thatdeadlock.
>
> My main thread is blocked by DRb.thread.join. All other threads are
>  inside the DRb library on either Socket#accept, #read or #write.

And, are there any locks held?

>  How can there be a deadlock if a thread is waiting in a Socket#accept
>  call? As I understand the Ruby deadlock detection is simply fires when
>  there is no thread to run.
>
>  > You could use set_trace_func to trace program execution until thedeadlockand look at the execution flow.
>
>  I have tried this, but it doesn't show anything other that the
>  deadlock report from Ruby, i.e. that the threads are calling
>  Socket#accept, #read or #write and Thread#join.

These issues are next to impossible to debug without access to code
and an understanding of what the app really does.  I'm afraid, I can't
help you further right now.

Kind regards

robert

-- 
use.inject do |as, often| as.you_can - without end