wxruby-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Wxruby-dev] Good news on threading


From: Kevin Smith
Subject: [Wxruby-dev] Good news on threading
Date: 06 Jul 2003 22:35:09 -0700

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

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.

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








reply via email to

[Prev in Thread] Current Thread [Next in Thread]