RE: [Wxruby-dev] Good news on threading

[Curt Hibbs]

Kevin Smith wrote:
>
> I was going to wait until it was further along to announce it, but I've
> been testing wxruby this weekend by writing...an email client! Since
> email clients are named after trees, and ruby is red, my email client is
> named 'redwood'.
>
> So far, it can POP'ing mail, show a list of messages with a preview
> window, delete messages to a trash folder, and compose (but not send)
> new mail. It has a menu, a toolbar, and a multi-tab main window (like a
> tabbed browser or IDE).
>
> Along the way, I learned a LOT about how sizers work, and how ListCtrl
> works. And I've had to add several missing methods and classes to
> wxruby. Over time, I'll try to add that info to the wiki. If someone
> wants to copy this to the wiki for me, I won't complain :-)

Excellent! There's no better way to excercise a framework (GUI or not) than
to use it for something real.

I can "throw" this up on the wiki for now, but sometime soon I need rework
and update the entire site as it is woefully out of date.

> Tonight, I looked more at threads, because I wanted to retrieve mail in
> the background. By default, the retreive thread was only getting slices
> while there is UI activity in the window. As soon as the user stopped
> doing stuff, the background thread stalled. Fortunately, I found a
> solution that I think will work for most people most of the time.
>
> In my main frame, I set up an event handler for idle events:
>     evt_idle { |event| on_idle(event) }
>
> In my on_idle method, I first check to see whether I actually have a
> background thread right now. In my case, I set a flag when I start the
> background mail checking thread, and clear it when the thread is
> finished.
>
> So the start of my on_idle handler looks like this:
>     def on_idle(event)
>         if(@mail_checker.checking)
>             event.request_more
>
> This means that when I have a background thread that needs time,
> wxWindows will keep feeding me idle events. When I don't, I will stop
> getting idle events, so I'm not always consuming CPU cycles.

Seems workable. Does cpu peg at 100% when you a processing a background
task?

> Just before terminating, my thread sets a flag to indicate that messages
> have been retrieved. At the bottom of my idle handler, I detect this
> case, and update the folder display. Cool.
>
> Unfortunately, there's still a several second pause between clicking on
> "check mail" and when the UI starts responding. That's because the call
> to set up the POP3 session doesn't allow other threads to run. Bummer.
> Still, it's good enough.
>
> Kevin

Also, thanks for checking in the changes I brought up a few days ago. I
haven't had time yet to do a Windows build again. I'll try to get to it
soon.

Curt