4 ms·

Any time you see "atomic", you can make a queue. A practical application of atomic mv is building simple file based queuing mechanisms. For example I wrote th

Any time you see "atomic", you can make a queue. A practical application of atomic mv is building simple file based queuing mechanisms. For example I wrote this SMTP buffer server which moves things to different directories as a simple form of message queue. https://github.com/bootrino/arniesmtpbufferserver https://github.com/bootrino/arniesmtpbufferserver It's pretty simple - ~100 lines of Python without comments etc. https://raw.githubusercontent.com/bootrino/arniesmtpbufferserver/master/arniesmtpbufferserver.py https://raw.githubusercontent.com/bootrino/arniesmtpbufferse... Caveat I think this needs examination from the perspective of fsync - i.e. I suspect the code should be fsyncing at certain points but not sure. I also wrote (in Rust) a simple file based message queue using atomic mv. It instantly maxed out the SSD performance at about 30,000 messages/second.

chasil 3y ago
One application of this could be writing to a SQLite database. If you wrap your writes in a shell script controlled by a lock directory, you are guaranteed to never receive SQLITE_BUSY. #!/bin/sh until mkdir /var/tmp/mylock do sleep 1; done trap 'rmdir /var/tmp/mylock' ABRT EXIT FPE HUP INT QUIT SEGV TERM sqlite3 mydatabase.db 'INSERT INTO MYTABLE VALUES (1,2,3);' Since the mkdir() is atomic, the SQLite busy handler is now irrelevant with this approach. On Linux, there is also an flock utility, but it tends to need subshells which are not as efficient. EDIT: This does reduce the write performance to one of these executions per second. Simple inserts like this can hit a few dozen per second otherwise, as I have heard.