# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 10
# self = https://watcher.sour.is/conv/zhprhoq
@lyse How do you logically and atomically do this? I have a bit of a problem with designing yarnd like this since a feed could be written to at any time. Do I lock the feed whilst this process is happening so I can do this? 🤔
@lyse How do you logically and atomically do this? I have a bit of a problem with designing yarnd like this since a feed could be written to at any time. Do I lock the feed whilst this process is happening so I can do this? 🤔
@lyse How do you logically and atomically do this? I have a bit of a problem with designing yarnd like this since a feed could be written to at any time. Do I lock the feed whilst this process is happening so I can do this? 🤔
@lyse How do you logically and atomically do this? I have a bit of a problem with designing yarnd like this since a feed could be written to at any time. Do I lock the feed whilst this process is happening so I can do this? 🤔
@prologic In my case it's super easy, because I just do not worry about concurrent events at all. When I run the script, I'm definitely not adding to my feed. But for yarnd a mutex per feed would be my choice, yes. Or just one mutex should suffice for the current amount of users and well beyond.
@lyse Hmmm maybe given @abucci's comment in #5s6ctoq I _might_ use a queue for writes and when rotating a feed, write the contents of the feed but leave the last N lines where N is the configured -N/--max-cache-items. Rotate the feed (atomically) then write those last N items back from the recently written archived feed. Because concurrent writes are _usually_ safe on most UNIX systems.
@lyse Hmmm maybe given @abucci's comment in #5s6ctoq I _might_ use a queue for writes and when rotating a feed, write the contents of the feed but leave the last N lines where N is the configured -N/--max-cache-items. Rotate the feed (atomically) then write those last N items back from the recently written archived feed. Because concurrent writes are _usually_ safe on most UNIX systems.
@lyse Hmmm maybe given @abucci's comment in #5s6ctoq I _might_ use a queue for writes and when rotating a feed, write the contents of the feed but leave the last N lines where N is the configured -N/--max-cache-items. Rotate the feed (atomically) then write those last N items back from the recently written archived feed. Because concurrent writes are _usually_ safe on most UNIX systems.
@lyse Hmmm maybe given @abucci's comment in #5s6ctoq I _might_ use a queue for writes and when rotating a feed, write the contents of the feed but leave the last N lines where N is the configured -N/--max-cache-items. Rotate the feed (atomically) then write those last N items back from the recently written archived feed. Because concurrent writes are _usually_ safe on most UNIX systems.
@lyse Hmmm maybe given @abucci's comment in #5s6ctoq I _might_ use a queue for writes and when rotating a feed, write the contents of the feed but leave the last N lines where N is the configured -N/--max-cache-items. Rotate the feed (atomically) then write those last N items back from the recently written archived feed. Because concurrent writes are _usually_ safe on most UNIX systems.