Forum: Ruby Net::Imap thread safety

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ingmar (Guest)
on 2008-10-17 15:12
(Received via mailing list)
Hi,

I have some problems with the Net::Imap standard library. In the docs,
it claims to supports concurrent threads. However, running a lot of
multiple threads invoking the same IMAP command on a Net::Imap object
results in errors:

undefined method `[]' for nil:NilClass (NoMethodError)

The exact places where the error occurs are different depending on
whether Ruby 1.8 or 1.9 are used. Here's an example program spawning a
lot of concurrent threads:

#!/usr/bin/env ruby -w
require 'net/imap'

$HOST      = ""
$PORT      = 993
$SSL       = true
$AUTH_MECH = "LOGIN"

$USER      = ""
$PASSWORD  = ""

conn = Net::IMAP.new($HOST, $PORT, $SSL, nil, false)
conn.authenticate($AUTH_MECH, $USER, $PASSWORD)

threads = []
100.times do
  threads << Thread.new do
    conn.capability
  end
end
threads.each { |t| t.join }

(you will need to specify your own server/login data)

Ruby 1.8 will usually terminate at /usr/lib/ruby/1.8/net/imap.rb:
314:in `capability'
Ruby 1.9 will usually terminate at /usr/lib/ruby/1.9.0/net/imap.rb:
317:in `block in capability'

Apparently (from looking at the source)
@responses.delete("CAPABILITY") seems to return Nil. Net::Imap is
using Monitor to synchronize access to @responses, however I can't
imagine Monitor to be flawed.

Is it possible that I'm simply querying the server too frequently? If
so, shouldn't Net::Imap's error handling be improved at this point?
Because it's hard for someone using the same Net::Imap object in
concurrent threads to limit the frequency of the access.

Thanks for your thoughts!
This topic is locked and can not be replied to.