Of GUIs threads and scheduling woes

[Glen Holcomb]

[Note: parts of this message were removed to make it a legal post.]

I have a small GUI app that I have written the purposes for it's creation
are two-fold and irrelevant. Here is my problem:

I have two threads aside from the main thread. One that wakes machines at
scheduled times and another that shuts them down at scheduled times.
Unfortunately Ruby's scheduler seems to care less when a thread actually
wakes up as long as it doesn't wake up early. Sometimes I have a five
minute (wall time) gap between when the thread should wake and when it
actually does.

The observed behavior seems to be magnified/caused by minimizing the
application. Does anyone have any suggestions that could lead to a more
responsive app? 5+ minutes late wouldn't matter so much if it didn't cause
the thread to miss an event scheduled a minute or two after the one that was
late. I suppose I could re-structure my code and may have to. I was just
hoping that there is a way to get tolerable responsiveness out of a thread.

-Glen

 

[Farrel Lifson]

hoping that there is a way to get tolerable responsiveness out of a thread.

You could move scheduling into a seperate process which is not
potentially blocked by waiting threads.

Farrel

 

[ara.t.howard]

The observed behavior seems to be magnified/caused by minimizing the
application. Does anyone have any suggestions that could lead to a
more
responsive app? 5+ minutes late wouldn't matter so much if it
didn't cause
the thread to miss an event scheduled a minute or two after the one
that was
late. I suppose I could re-structure my code and may have to. I
was just
hoping that there is a way to get tolerable responsiveness out of a
thread.

this sounds alot like a process being put to sleep by windows and
thereby causing all threads to sleep - is this on windows?

a @ http://codeforpeople.com/

 

[Glen Holcomb]

[Note: parts of this message were removed to make it a legal post.]

On Jul 23, 2008, at 10:36 AM, Glen Holcomb wrote:

The observed behavior seems to be magnified/caused by minimizing the



this sounds alot like a process being put to sleep by windows and thereby
causing all threads to sleep - is this on windows?

a @ http://codeforpeople.com/

Unfortunately it is, which is what I had feared was happening. I'm not sure
if being out of focus for a prolonged time has the same effect or not. I
was planning on testing that shortly.

It would appear there is no way around this and that I will need separate
processes. I noticed the mmap library is pretty old, is it reliable? DRb
would do what I need but I'd rather do it without opening ports since all
the processes would be on the same machine anyway.

 

[Glen Holcomb]

[Note: parts of this message were removed to make it a legal post.]

Unfortunately it is, which is what I had feared was happening. I'm not
sure if being out of focus for a prolonged time has the same effect or not.
I was planning on testing that shortly.

It would appear there is no way around this and that I will need separate
processes. I noticed the mmap library is pretty old, is it reliable? DRb
would do what I need but I'd rather do it without opening ports since all
the processes would be on the same machine anyway.

--
"Hey brother Christian with your high and mighty errand, Your actions speak
so loud, I can't hear a word you're saying."

-Greg Graffin (Bad Religion)

I assume the problem stems from the fact that my "sub threads" are already
sleeping when the main thread is put to sleep?

 

[ara.t.howard]

Unfortunately it is, which is what I had feared was happening. I'm
not sure
if being out of focus for a prolonged time has the same effect or
not. I
was planning on testing that shortly.

It would appear there is no way around this and that I will need
separate
processes. I noticed the mmap library is pretty old, is it
reliable? DRb
would do what I need but I'd rather do it without opening ports
since all
the processes would be on the same machine anyway.

drb is the best best - just bind localhost and you'll be fine


a @ http://codeforpeople.com/

 

[Pit Capitain]

Unfortunately it is, which is what I had feared was happening.

Glen, what version of Windows are you using? I run a couple of
background scripts written in Ruby on both Windows 2000 and Windows XP
without problems. My scripts aren't multithreaded though.

Regards,
Pit

 

[Alex Fenton]

I have a small GUI app that I have written the purposes for it's creation
are two-fold and irrelevant. Here is my problem:

I have two threads aside from the main thread. One that wakes machines at
scheduled times and another that shuts them down at scheduled times.
Unfortunately Ruby's scheduler seems to care less when a thread actually
wakes up as long as it doesn't wake up early. Sometimes I have a five
minute (wall time) gap between when the thread should wake and when it
actually does.

The observed behavior seems to be magnified/caused by minimizing the
application. Does anyone have any suggestions that could lead to a more
responsive app? 5+ minutes late wouldn't matter so much if it didn't cause
the thread to miss an event scheduled a minute or two after the one that was
late. I suppose I could re-structure my code and may have to. I was just
hoping that there is a way to get tolerable responsiveness out of a thread.

Most of the GUI libraries for Ruby are based on C/C++ and while a GUI
app is running spend most of the time in an "event loop" - a bit of
native code which waits for user actions. As I understand it, ruby's
thread scheduler won't switch thread context whilst native extension
code - eg the event loop - is executing. So non-GUI ruby (green) threads
can get starved of execution time.

There are two possible solutions to this, the exact implementation of
which will depend on the toolkit. Both depend on using the
timing/regular event facilities provided by GUI toolkits, which will be
respected by the event loop - I've seen discussion relating to different
libraries. I'll use Wx as an example.

One is to regularly schedule time for the non-GUI threads, using Ruby's
Thread.pass. In wxRuby:

Wx::Timer.every(50) { Thread.pass }

This sets a Timer which will wake and run the subordinate threads every
50ms.

The other way is to dispense with Ruby's thread's altogether and just
use a timer. This may be more suitable for your use case:

Wx::Timer.after(5000) { DO SHUTDOWN ACTION... }

hth
alex

 

[Glen Holcomb]

[Note: parts of this message were removed to make it a legal post.]

Glen Holcomb wrote:

I have a small GUI app that I have written the purposes for it's creation

Most of the GUI libraries for Ruby are based on C/C++ and while a GUI app
is running spend most of the time in an "event loop" - a bit of native code
which waits for user actions. As I understand it, ruby's thread scheduler
won't switch thread context whilst native extension code - eg the event loop
- is executing. So non-GUI ruby (green) threads can get starved of execution
time.

There are two possible solutions to this, the exact implementation of which
will depend on the toolkit. Both depend on using the timing/regular event
facilities provided by GUI toolkits, which will be respected by the event
loop - I've seen discussion relating to different libraries. I'll use Wx as
an example.

One is to regularly schedule time for the non-GUI threads, using Ruby's
Thread.pass. In wxRuby:

Wx::Timer.every(50) { Thread.pass }

This sets a Timer which will wake and run the subordinate threads every
50ms.

The other way is to dispense with Ruby's thread's altogether and just use a
timer. This may be more suitable for your use case:

Wx::Timer.after(5000) { DO SHUTDOWN ACTION... }

hth
alex

Thanks for the tip Alex. I'll definitely look into it. I'm using Wx so
your example is perfect I've never done any GUI programming so part of
this experiment was to learn the nuances and at least one framework which I
appear to be doing.

To answer your question Pit I'm running this in Windows XP. I haven't had
problems with any of my other scripts either although this is the first
threaded code I've written in Ruby.

 

[Alex Fenton]

[Note: parts of this message were removed to make it a legal post.] Thanks for the tip Alex. I'll definitely look into it. I'm using Wx so
your example is perfect

You may want to have a look at this thread on the wxruby-users mailing
list, and also the previous threads linked to in the discussion

http://www.ruby-forum.com/topic/126821

cheers
alex

 

[Pit Capitain]

Thanks for the tip Alex. I'll definitely look into it. I'm using Wx so
your example is perfect I've never done any GUI programming so part of
this experiment was to learn the nuances and at least one framework which I
appear to be doing.

To answer your question Pit I'm running this in Windows XP. I haven't had
problems with any of my other scripts either although this is the first
threaded code I've written in Ruby.

OK, so it might well be an issue with the thread handling of your GUI
toolkit. Good luck fixing your problems.

Regards,
Pit

 

[Glen Holcomb]

[Note: parts of this message were removed to make it a legal post.]

OK, so it might well be an issue with the thread handling of your GUI
toolkit. Good luck fixing your problems.

Regards,
Pit

Alex,

The timer works beautifully, thanks!

-Glen