Need to call process_events on load?

[Will Brady]

I'm a little confused on when you need to call process_events. Using the example that Allan Nørgaard Kristensen posted in his previous question:

require 'hallon'

session = Hallon::Session.initialize IO.read("./spotify_app.key")

session.login("m...@email.com", "password")

print "[SESSION] Logging in ..."

while(session.status != :logged_in)

session.process_events

print "."

sleep(3)

end

puts " done!"

c = session.container

c.load

while(session.container.loaded? == false)

session.process_events

sleep(0.1)

end

p = c.contents.at(0).load

Calling session.login seems to not actually log you in immediately which is why you have to wait until you're logged in calling session.process_events continuously. I get that. However, when he calls c.load that seems to block for me and won't get to the while loop which looks like its supposed to do the same thing as login. So does load block and login not? How can you call process_events continuously if c.load blocks and you never get to that while loop? For me, c.load hangs forever.

I'm on Mac OS X 10.8 using hallon (0.18.1), spotify gem (12.3.0) and libspotify (12.1.51)

[Kim Burgestrand]

On Saturday, 23 February 2013 at 21:33, Will Brady via Hallon wrote:

I'm a little confused on when you need to call process_events. Using the example that Allan Nørgaard Kristensen posted in his previous question:

Yes, the example Allan posted is a little weird, since #load (http://rdoc.info/github/Burgestrand/Hallon/Hallon/Loadable#load-instance_method) will block until the object has been successfully loaded (or until the timeout is reached). The code `c = session.container; c.load` will thus guarantee that the session container has loaded. The while-loop contents after that, `session.container.loaded? == false`, will never run.

Calling session.login seems to not actually log you in immediately

No, it does not. Very few things in libspotify (and in effect, in Hallon too) are immediate, and pretty much everything is asynchronous by default. There is a Session#login! method that will wait until login is successful, or an error occurs.

So does load block and login not?

Yes. Loadable#load is one of the few methods that block (i.e. wait until a certain condition in libspotify is met). There are a few others; if a method is blocking it should be explicitly stated in the API reference for Hallon.

How can you call process_events continuously if c.load blocks and you never get to that while loop? For me, c.load hangs forever.

#load should never block forever and if it does, it’s a bug. It either blocks until the object has loaded successfully or, after `Hallon.load_timeout` seconds, raises a Hallon::TimeoutError.

With all this: process_events is called for you on the blocking methods, but it needs to be called in order for libspotify to be able to do any work (and it’s part of libspotify). libspotify was really built with an application that has a main loop in mind, for example a GUI application or node.js. In such an environment it would be much more natural to use libspotify. Hallon should really have been something more similar to eventmachine to make sense in ruby.

— Kim

[Bradley Jones]

I just replied in Allans question but seems more appropriate here.

I do find that c.load blocks forever while trying to load the session container.

This appears to be isolated to linux (am running code on the Raspberry Pi) as if I run under OSx the code does not block forever and the session container is actually loaded before c.load is called.

puts "#{session.container.loaded?}" # Returns true under OSx false under linux
c = session.container
c.load
puts "#{session.container.loaded?}" # Returns true under OSx because of the constant blocking this is never executed on the Pi