Hi, I'm wondering why we are using Connection.request instead of just Connection.sendMessage.
The point of having Connection.askMessage is connecting the reply to the answer ... so that the calling thread can be blocked until the answer has been received. It's for making an asynchronous process synchronous. Yet the process is made asynchronous again by calling the handler in Connection.request. The main difference between Connection.request and Connection.sendMessage is that the caller to the former gets blocked until the reply has arrived, while for the latter it does not. Please note that this only happens for the calling thread ... there's nothing preventing another thread from making another request at the same time. The reply we are waiting for can already have been invalidated. The value of this type of locking is dubious. I am also noticing that we are calling Connection.request from the Event Dispatching Thread. This makes the user interface block until the answer has been received. The Connection.askMessage, and by extension Connection.request, should only be called from worker threads. In addition, any time it is used we need to consider when to abort the execution and if a timeout should be added to the call. Changing the implementation of Connection.request to use sendMessage instead of askMessage works most of the time, but there are some places where we expect the update from the server to have been received and processed before the next statement is executed. Most notably "moveUnit". There are two approaches we can use instead of the current solution: 1. Have a completely asynchronous process when sending messages. 2. Execute Connection.request/askMessage on separate threads (either popup-threads or have a thread poll/ExecutorService). Best wishes, Stian Grenborgen _______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
