[Freeciv-Dev] Re: (PR#3513) GUI is unresponsive while handling network e
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
[Freeciv-Dev] Re: (PR#3513) GUI is unresponsive while handling network events
"Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Mon, 24 Feb 2003 02:34:30 -0800
Raimar Falke wrote:
> On Sun, Feb 23, 2003 at 11:52:24PM -0800, Jason Short wrote:
>>While the client is in the network loop, no user-interface events are
>>handled. This means operations like closing popup windows and redrawing
>>areas that have been invalidated (e.g., by being covered by those popup
>>windows) don't get done until the end of the network loop.
> The only way I know to avoid this is to use multi-threading. However
> this will only solve this problem partially. The network thread will
> set the data to an inconsistent state in a regular way. The GUI thread
> however won't be amused about inconsistent state. This is a normal
> problem of multi-threading programming. It is solved by locks. But
> even when we would use threads and locks I don't think the result will
> be complete since most of the network code will be run with the lock
> held. So little gain for a lot of work.
It's not true that the only solution is multi-threading, but it seems
likely that there is no good full solution.
If the network code only handled one (or a small number of) packet at a
time, then when it returned the GUI would handle events before
re-entering the network code. The drawback is it would make the drawing
code hideously slow.
GTK allows you to call a function (gtk_event_iterate or some such) that
will handle a single event. This could be called periodicly through the
network loop. But then we are likely to get more network events and
have the network code re-enter - and it is also likely to make the
drawing code somewhat slow.
There are really only a few events that we need to worry about, though.
It may be possible to poll for these events without losing too much
efficiency or needing too much code. One example is the flush_dirty
patch, which will handle mapcanvas expose events every time
flush_dirty() is called. Other GUIs aren't likely to have as slick an
interface as gtk+-2.0, so this is probably less helpful elsewhere.