Threading best practices?

[Dolazy]

I am developing a small GUI application using jruby. It will be used
for testing API calls to my company's server. I would like my
application to execute server calls in a non-blocking way. In C++ I do
this by creating a worker thread that executes the call and then
invokes a postback to the main thread (similar to Java's InvokeLater).

How do I do this in Ruby?

My simplified code looks something like this:

def get_users
Thread.new(server, successCallback, errorCallback) do |server, scb,
ecb|
res = Net::HTTP.post_form(server, { "action" => "getUsers"})
if res.body
scb.call(res.body) # => this should be wrapped in some sort of
InvokeLater ?
else
ecb.call("getUsers failed") # => this too
end
end
end

I would prefer to use the Ruby standard library over the Java library.

Eager to learn,
Francis

 

[Robert Klemme]

I am developing a small GUI application using jruby. It will be used
for testing API calls to my company's server. I would like my
application to execute server calls in a non-blocking way.

What does the rest of the application do in the meantime?

How do I do this in Ruby?

My simplified code looks something like this:

def get_users
Thread.new(server, successCallback, errorCallback) do |server, scb,
ecb|
res = Net::HTTP.post_form(server, { "action" => "getUsers"})
if res.body
scb.call(res.body) # => this should be wrapped in some sort of
InvokeLater ?
else
ecb.call("getUsers failed") # => this too
end
end
end

I would prefer to use the Ruby standard library over the Java library.

Not sure what exactly you mean by "InvokeLater". Do you want to pass
the result of method calls back to the calling thread? Or do you want
to asynchronously invoke callbacks?

One thing which might be useful for you is Thread#value which joins a
thread and returns the last value:

robert@fussel ~
$ ruby -e 'puts Time.now;t=Thread.new {sleep 1; 123};puts t.value, Time.now'
Mon Oct 20 22:28:28 +0200 2008
123
Mon Oct 20 22:28:29 +0200 2008

robert@fussel ~
$

Another option is to set up a Queue for feedback which is queried from
the main thread. It all depends on what you application does or what
you want to achieve. Can you give more detail?

Kind regards

robert

 

[Dolazy]

What does the rest of the application do in the meantime?

Anything that the user is doing at that time. I want to avoid freezing
the GUI.

Not sure what exactly you mean by "InvokeLater".  Do you want to pass
the result of method calls back to the calling thread?

Yes, that's exactly what I have in mind.

Another option is to set up a Queue for feedback which is queried from
the main thread.  It all depends on what you application does or what
you want to achieve.  Can you give more detail?

For example, one of the first calls will be the login method. In a
worker thread I want to send the login message, receive the response,
and then notify the main thread of either a successful or failed
login, by means of invoking the corresponding callback.

 

[david_koontz]

=20

Anything that the user is doing at that time. I want to avoid freezing
the GUI.
=20
=20
Yes, that's exactly what I have in mind.
=20
=20
For example, one of the first calls will be the login method. In a
worker thread I want to send the login message, receive the response,
and then notify the main thread of either a successful or failed
login, by means of invoking the corresponding callback.
=20

I'm going to out on a limb and assume you're using Swing here. To keep the
GUI painting properly and new events being processed you have to make sure
the EDT (event dispatch thread) does not block. So in your event handler
you need to spin off a new thread and return as fast as possible to prevent
"laggyness" in the UI. This does mean you need some asynchronous way of
getting your response, a queue is probably your best bet here (plus it's
thread safe). In Monkeybars, we used a library named Foxtrot (Java lib)
that processed GUI redraw events (but not new actions) while an action was
being performed. For short-lived processes this worked great and prevented
the mess of having to get data back from an asynchronous thread.

David Koontz

--=20
View this message in context: http://www.nabble.com/Threading-best-practice=
s--tp20077301p20081656.html
Sent from the ruby-talk mailing list archive at Nabble.com.

 

[Dolazy]

I'm going to out on a limb and assume you're using Swing here.  To keepthe
GUI painting properly and new events being processed you have to make sure
the EDT (event dispatch thread) does not block.  So in your event handler
you need to spin off a new thread and return as fast as possible to prevent
"laggyness" in the UI.  This does mean you need some asynchronous way of
getting your response, a queue is probably your best bet here (plus it's
thread safe).  InMonkeybars, we used a library named Foxtrot (Java lib)
that processed GUI redraw events (but not new actions) while an action was
being performed.  For short-lived processes this worked great and prevented
the mess of having to get data back from an asynchronous thread.

David Koontz

Yeah I started using MonkeyBars. I find it a very interesting project,
but complicated to learn (may also since the tutorial videos don't
seem to work I'm gonna stick to it though because it combines so
much great stuff (Ruby style, Swing power, "neo"-MVC, neat folder
structure, deployment, ...)

 

[david_koontz]

Yeah I started using MonkeyBars. I find it a very interesting project,
but complicated to learn (may also since the tutorial videos don't
seem to work I'm gonna stick to it though because it combines so
much great stuff (Ruby style, Swing power, "neo"-MVC, neat folder
structure, deployment, ...)

Much apologies for the tutorial videos not working. We did a bit of server
shuffling a while back and apparently I never got the video files back
online. I have fixed this and the last few files will be online within a
half hour. Hopefully that will help a lot with the "getting started"
business.

David Koontz