[Freeciv-Dev] Re: (PR#3513) GUI is unresponsive while handling network events

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

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.

jason