Jamis:
Yap. That did the trick. Cool!
Everything works with cap2 just fine. Haven't deployed any real app
yet. It
would be nice to get a general update/plans on cap2 specifically the
opt-in
stuff.
Thanks
On Apr 11, 9:12 pm, Jamis Buck [EMAIL PROTECTED] wrote:
As a follow up to Ezra's email,
FYI:
I still receive the rake error. SVN rev - 6512
Cheers
On Mar 30, 9:40 pm, Jamis Buck [EMAIL PROTECTED] wrote:
Ah! Brilliant, Doug. Thanks for the patch! That cleared the problem
right up.
- Jamis
On Mar 30, 2007, at 12:51 PM, Doug Barth wrote:
The problem here is that your
On Apr 11, 2007, at 5:10 AM, rubdabadub wrote:
FYI:
I still receive the rake error. SVN rev - 6512
The deadlock when running rake, you mean? What ruby version are you
using? What is your operating system?
- Jamis
Cheers
On Mar 30, 9:40 pm, Jamis Buck [EMAIL PROTECTED] wrote:
Ah!
Hmmm, looks like a Ruby 1.8.6 thing. It works fine on 1.8.5, but I
can duplicate it too with 1.8.6.
I'll make some time this week to investigate this a bit.
- Jamis
On Apr 11, 2007, at 7:27 AM, rubdabadub wrote:
Yes, The deadlock error. I am on OSX 10.4 and ruby 1.8.6 (2007-03-13
Ruby 1.8.6 has replaced the Thread classes with the fastthread
implementation. Unfortunately there is a bug in the release of 1.8.6
that has to do with threading that will hopefully be fixed in the
next release.
For now install the fastthread gem and then somewhere in the
Brilliant, sure enough, Ezra. That did it. I love it when people do
the dirty work for me. :)
Yay! It wasn't my fault!
- Jamis
On Apr 11, 2007, at 1:04 PM, Ezra Zygmuntowicz wrote:
Ruby 1.8.6 has replaced the Thread classes with the fastthread
implementation. Unfortunately there
As a follow up to Ezra's email, I've added a check for the fastthread
library if ruby version 1.8.6 is detected. Let me know if that makes
any difference. It cleared things right up, for me.
- Jamis
On Apr 11, 2007, at 7:27 AM, rubdabadub wrote:
Yes, The deadlock error. I am on OSX 10.4
Yeah...I've not been able to figure that out. It only happens
intermittently to me. If you go into test/gateway_test.rb and comment
out the
test_initialize_when_connect_lags_should_open_and_set_session_value
test (lines 13-17), it should go away.
Any threading/concurrency gurus around
The problem here is that your signaling thread is signaling before the
originating thread has had the chance to wait on the condition. This
results in the wait hanging forever waiting for a signal. The fix is
to synchronize the creation of the background thread as well. Here's a
patch that fixes
