[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Of GUIs threads and scheduling woes

Glen Holcomb

7/23/2008 4:36:00 PM

[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

--
"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)

11 Answers

Farrel Lifson

7/23/2008 5:53:00 PM

0

2008/7/23 Glen Holcomb <damnbigman@gmail.com>:
I was just
> 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
--
Aimred - Ruby Development and Consulting
http://www....

ara.t.howard

7/23/2008 6:22:00 PM

0


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

> 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://codeforp...
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama




Glen Holcomb

7/23/2008 6:43:00 PM

0

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

On Wed, Jul 23, 2008 at 12:21 PM, ara.t.howard <ara.t.howard@gmail.com>
wrote:

>
> On Jul 23, 2008, at 10:36 AM, Glen Holcomb wrote:
>
> 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://codeforp...
> --
> we can deny everything, except that we have the possibility of being
> better. simply reflect on that.
> h.h. the 14th dalai lama
>
>
>
>
>
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)

Glen Holcomb

7/23/2008 6:47:00 PM

0

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

On Wed, Jul 23, 2008 at 12:48 PM, Glen Holcomb <damnbigman@gmail.com> wrote:

> On Wed, Jul 23, 2008 at 12:21 PM, ara.t.howard <ara.t.howard@gmail.com>
> wrote:
>
>>
>> On Jul 23, 2008, at 10:36 AM, Glen Holcomb wrote:
>>
>> 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://codeforp...
>> --
>> we can deny everything, except that we have the possibility of being
>> better. simply reflect on that.
>> h.h. the 14th dalai lama
>>
>>
>>
>>
>>
> 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?

--
"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)

ara.t.howard

7/23/2008 8:03:00 PM

0


On Jul 23, 2008, at 12:43 PM, Glen Holcomb wrote:

> 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://codeforp...
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama




Pit Capitain

7/24/2008 6:33:00 AM

0

2008/7/23 Glen Holcomb <damnbigman@gmail.com>:
> On Wed, Jul 23, 2008 at 12:21 PM, ara.t.howard <ara.t.howard@gmail.com>
> wrote:
>> this sounds alot like a process being put to sleep by windows and thereby
>> causing all threads to sleep - is this on windows?
>>
> 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

7/24/2008 8:30:00 AM

0

Glen Holcomb wrote:

> 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

7/24/2008 12:55:00 PM

0

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

On Thu, Jul 24, 2008 at 2:24 AM, Alex Fenton <alex@deleteme.pressure.to>
wrote:

> Glen Holcomb wrote:
>
> 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
>
>
>
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.

--
"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)

Alex Fenton

7/24/2008 2:27:00 PM

0

Glen Holcomb wrote:
> [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/to...

cheers
alex

Pit Capitain

7/24/2008 2:29:00 PM

0

2008/7/24 Glen Holcomb <damnbigman@gmail.com>:
> 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