#6 gnopa uses 100% CPU, even when idle

[David Costanzo]

When I run gnopa, it consumes 100% of my CPU, even when
it is sitting idle. I think it uses low-priority
threads, because I haven't noticed other applications
getting as sluggish. Still, it's something that can be
remedied.

I found two causes: the gui_loop and the action_loop.

The first cause is that the gui_loop runs when the GTK
loop is idle. The CVS history says that this is a
deliberate and that it allows the gui_loop to respond
faster. While that is true, I don't think it makes the
GUI more responsive from the user's point of view.
There is a limit to how quickly people can process
changes in their visual field. For a simple GUI, 10
frames per second should be sufficent.

The second cause is that the action_loop activly polls
the action queue, instead of blocking until an action
is availible.

I have attached patch for callbacks.c that turns
gui_loop back into a 100 ms timer event and makes the
action_loop block until an action is availible. gnopa
no longer pegs the CPU and performance seems fine. (Of
course, this is the first time I've really used gnopa,
so I don't know what performance is supposed to be like).

My fix for the gui_loop is less-than-ideal. Instead of
being a timer event, the part that updates the UI and
unblocks the action_loop could be reworked into a
user-defined signal handler that the action_loop
raises. However, I am unfamilar with GTK programming
and I don't know how to generate user-defined signals.
In any event, the timer adds a worse-case 1/10th
second delay to a 30 second file transfer, so its not
really noticable.

[David Costanzo]

Logged In: YES
user_id=109252

Hmmm, looks like I forgot to check the "Check to Upload and
Attach a File" box. Here's another try.

[David Costanzo]

A patch for callbacks.c in $/gnopa/src