Hello, Any ideas how to make frames not to freeze when running events? I tried using threads, but they won''t finish, and when using Thread.join the effect is same as not using threads at all (= gui freezing). Thanks, Raine
Raine Virta wrote:> Any ideas how to make frames not to freeze when running events? I tried > using threads, but they won''t finish, and when using Thread.join the > effect is same as not using threads at all (= gui freezing). >Could you give us a bit more detail about the problem - is it that an event handler launches some long-running code? There was a recent discussio on preventing non-GUI threads being starved of execution time starting here: http://rubyforge.org/pipermail/wxruby-users/2007-April/003047.html and what seems the best solution: http://rubyforge.org/pipermail/wxruby-users/2007-April/003055.html alex
Alex Fenton wrote:> Raine Virta wrote: > >> Any ideas how to make frames not to freeze when running events? I tried >> using threads, but they won''t finish, and when using Thread.join the >> effect is same as not using threads at all (= gui freezing). >> >> > Could you give us a bit more detail about the problem - is it that an > event handler launches some long-running code? > > There was a recent discussio on preventing non-GUI threads being starved > of execution time starting here: > > http://rubyforge.org/pipermail/wxruby-users/2007-April/003047.html > > and what seems the best solution: > > http://rubyforge.org/pipermail/wxruby-users/2007-April/003055.html > > alex > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users >Yes, event handler launches some code that could take a while. I also tried what you suggested, here''s the whole script: http://pastie.caboo.se/private/zikfdphzngzmo5jx3z Lines 225, 250 and 260+ are significant. Most likely I''m doing something wrong but I can''t figure out what. The problem is still that the thread won''t run completely.
Raine Virta wrote:> Alex Fenton wrote: > >> Raine Virta wrote: >> >> >>> Any ideas how to make frames not to freeze when running events? I tried >>> using threads, but they won''t finish, and when using Thread.join the >>> effect is same as not using threads at all (= gui freezing). >>> >>> >>> >> Could you give us a bit more detail about the problem - is it that an >> event handler launches some long-running code? >> >> There was a recent discussio on preventing non-GUI threads being starved >> of execution time starting here: >> >> http://rubyforge.org/pipermail/wxruby-users/2007-April/003047.html >> >> and what seems the best solution: >> >> http://rubyforge.org/pipermail/wxruby-users/2007-April/003055.html >> >> alex >> _______________________________________________ >> wxruby-users mailing list >> wxruby-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wxruby-users >> >> > Yes, event handler launches some code that could take a while. I also > tried what you suggested, here''s the whole script: > > http://pastie.caboo.se/private/zikfdphzngzmo5jx3z > > Lines 225, 250 and 260+ are significant. > > Most likely I''m doing something wrong but I can''t figure out what. The > problem is still that the thread won''t run completely. > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > >Hey Raine, I''ve looked over your code, and ran a few test runs on my system here. I was able to run it, and it would download the pictures, but would take long intermittent times (Longer then what it actually takes to download the picture) Part of the problem, that I can see, is that with dealing with TCP Sockets, that Ruby will not go into Non-Blocking mode, and sometimes, that may cause wxRuby to throw off it''s timing, and may cause the what seems like an long time to run, actually is just taking a bit for it to complete. Part of the reason why I wish wxRuby2 still had the Sockets built in. Even though, Ruby has that functionality, and it''s stable, and good, it leaves much to be desired when attempting to interface with a GUI, which causes part of the problems with Blocking of UI Events. Atleast with the wxRuby interface, the Already existing handlers for Sockets would allow the GUI to respond, cause all the events for handling both Sockets, and UI events was built into the main_loop thread. But since that has been opted out, a work around needs to be developed to prevent what is going on with your program, from occuring. What I can report, is that the downloading of the Pictures do occur faster, if you tap on the random button a few times, but at the same time, the Random sometimes acts slow and causes the UI to freeze up. I''m thinking, this is cause your querying the PHP script you have to randomly generate a name, and send it back to the client. Correct me if I''m wrong, but that''s what I read from the script. Only thing I can suggest, is read up on Socket, and look for the way that Ruby changes a Socket from Blocking to Non-Blocking, to allow the UI to respond. L8ers, Mario Steele -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20070503/5e08db4c/attachment.html
Mario Steele wrote:> Part of the problem, that I can see, is that with dealing with TCP > Sockets, that Ruby will not go into Non-Blocking mode, and sometimes, > that may cause wxRuby to throw off it''s timing, and may cause the what > seems like an long time to run, actually is just taking a bit for it > to complete. Part of the reason why I wish wxRuby2 still had the > Sockets built in.Generally the idea is to encourage the use of ruby''s cross-platform abstractions of eg socket over Wx''s classes, but I''m not absolutely opposed to porting Wx::Socket if they''re going to work better with the GUI. Certainly seems the case with Wx::Timer vs ''timeout'' alex
Alex Fenton wrote:> Generally the idea is to encourage the use of ruby''s cross-platform > abstractions of eg socket over Wx''s classes, but I''m not absolutely > opposed to porting Wx::Socket if they''re going to work better with the GUI. > > Certainly seems the case with Wx::Timer vs ''timeout'' > > alex >I''m all for using Ruby''s cross-platform abstractions, when appropriate. But yes, as pointed out, this is not one of those cases. It''s part of the reason why I got into wxWidgets a long time ago, cause of the problems that can occur across platforms when dealing with Sockets. If your willing to do it, I''m all for it, cause my current project is going to be heavily relying on Sockets, and I''d rather not run into the same problems. Anyways, thanks for a great stable release Alex. It''s looking great. Mario Steele