atomic file write
-
I have a simple server app that uses WritePrivateProfileString() when a client changes the status of a user. I want to protect against multiple 'change status' requests resulting in clashing file writes. The clients communicate with the server using UDP and the server uses a listener socket. The listener socket uses 'OnReceive()' to call a function to write to the data file. I've been using a temp file to write to and then delete the working file then rename the temp file. It works most of the time but once in a while the main data file is deleted and there is no temp file. It's a bug but I'm wondering if there is a better way? Thank you.
-
I have a simple server app that uses WritePrivateProfileString() when a client changes the status of a user. I want to protect against multiple 'change status' requests resulting in clashing file writes. The clients communicate with the server using UDP and the server uses a listener socket. The listener socket uses 'OnReceive()' to call a function to write to the data file. I've been using a temp file to write to and then delete the working file then rename the temp file. It works most of the time but once in a while the main data file is deleted and there is no temp file. It's a bug but I'm wondering if there is a better way? Thank you.
Does each client get serviced on a separate thread by the server? If yes, you'll need to use some kind of synchronization object while writing to the file. A
CRITICAL_SECTIONmight do nicely for you.-- gleat http://blogorama.nerdworks.in[^] --
Number Two's eyes narrowed and became what are known in the Shouting and Killing People trade as cold slits, the idea presumably being to give your opponent the impression that you have lost your glasses or are having difficulty keeping awake. Why this is frightening is an, as yet, unresolved problem. -- HHGTG
-
Does each client get serviced on a separate thread by the server? If yes, you'll need to use some kind of synchronization object while writing to the file. A
CRITICAL_SECTIONmight do nicely for you.-- gleat http://blogorama.nerdworks.in[^] --
Number Two's eyes narrowed and became what are known in the Shouting and Killing People trade as cold slits, the idea presumably being to give your opponent the impression that you have lost your glasses or are having difficulty keeping awake. Why this is frightening is an, as yet, unresolved problem. -- HHGTG
-
I'm using a single instance of the listener socket. Would that be enough to ensure the file is only written by one client at a time?
What do you do when your "accept" (or the equivalent Windows socket extensions API) call returns? Do you launch another thread to respond to the client socket returned by "accept"? If you are doing it on the same thread as the one that invokes "accept" then you shouldn't require synchronization; in which case the problem lies elsewhere.
-- gleat http://blogorama.nerdworks.in[^] --
Number Two's eyes narrowed and became what are known in the Shouting and Killing People trade as cold slits, the idea presumably being to give your opponent the impression that you have lost your glasses or are having difficulty keeping awake. Why this is frightening is an, as yet, unresolved problem. -- HHGTG
-
What do you do when your "accept" (or the equivalent Windows socket extensions API) call returns? Do you launch another thread to respond to the client socket returned by "accept"? If you are doing it on the same thread as the one that invokes "accept" then you shouldn't require synchronization; in which case the problem lies elsewhere.
-- gleat http://blogorama.nerdworks.in[^] --
Number Two's eyes narrowed and became what are known in the Shouting and Killing People trade as cold slits, the idea presumably being to give your opponent the impression that you have lost your glasses or are having difficulty keeping awake. Why this is frightening is an, as yet, unresolved problem. -- HHGTG
-
I have a pointer to the server object (the object that created the listener socket), and I call a function in that server object. No additional threads. Thank you for your time on this.
OK. You might want to conduct a little experiment. From your "OnReceive" handler, trace the return value of "GetCurrentThreadId" to a log and have multiple clients connect simultaneously to the server. Now inspect the log to see if the values logged are the same for all the clients. Also, is there a code snippet that you can post that shows how you are doing the file processing?
-- gleat http://blogorama.nerdworks.in[^]