Follow-up Comment #4, patch #3721 (project freeciv):
Not being thread safe isn't just about whether the client is multithreaded.
The entire computational system (client+server) has at least two threads, and
if I read unit_move() correctly, send_unit_info_to_onlookers() is called a few
times before the transported units are moved, so that there is a window during
which the client sees the transporting unit moved and the transported units
not yet moved, because the client thread (the single thread of the client
process) isn't waiting for the server to finish with unit_move_handling() to
do the next action. In practice, the situation described above would require
either extremely variable network latency or a vast disparity in computational
power between the client and the server, but this definitely conceivable with
a fast gaming PC running the client and a heavily-loaded public internet
server running on aging donated hardware in the lowest QoS band of some
oddly-connected data centre.
Note that in the situation above, although the units are on different tiles,
they still believe themselves to be transported, so by querying transport
status, the information collected can be expected to also be reliable once the
server has finished processing the move (and since the information that the
transport is no longer occupied is sent before the information that the unit
has moved, the opposite case (thinking a unit is in a transport when it has in
fact moved out) will never occur with the current code).
_______________________________________________________
Reply to this item at:
<http://gna.org/patch/?3721>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
