From: david_koontz Date: 2008-10-21T09:55:14+09:00 Subject: Re: Threading best practices? Dolazy wrote: > > On 20 okt, 22:29, Robert Klemme wrote: >> On 20.10.2008 21:42, Dolazy wrote: >> >> > 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? > 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. > 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 -- View this message in context: http://www.nabble.com/Threading-best-practices--tp20077301p20081656.html Sent from the ruby-talk mailing list archive at Nabble.com.