Usually a server is a server because it does not act, it reacts i.e. serves. If you keep your communication that way, you have a lot less problems (especially if you are a novice in that area)

For example your while loop in the read_data thread is endless if your client just breaks the connection (which I assume might be your problem, you don't show the client code so I have to guess). Your client usually has to tell the server "I'm done". You either have to send an EOF or some command which signals the end.

Your client and your server have to know at what times each one has to send anything. Such a proper handshake makes sure that client and server don't wait both for a communication from the other side. Usually this is done by defining commands that the client sends to the server and the server has to answer (naturally to make this safe from network problems you still have to have some timeout which breaks the connection after waiting too long, but that can be ignored for a first simple solution).

So the client might have a command "send gps" and the server answers either with the gps data or an error code which might signify that something is wrong or that it just needs more time to get gps data. In the second case the clients waits a second (or whatever time seems sensible) and then sends the command "send gps" again. Notice this makes it possible for the client to wait for an answer of the server, it is called "polling". Or instead of polling the client simply has to wait until the server has calculated the answer.

Now it is entirely possible and no problem for the client and the server to change roles (even in the middle of the connection). Then the server initiates new communications, sends the commands and tells the client when the communication has finished or when the roles reverse again. But this makes your script more and more complex and you need a lot more than your simple while loop to get this working