Re: Custom timer module

[ludovic@demblans.com]

Thank you very much for those advices, I'll see if I can apply that to my code !

Cheers

Le Mardi, Janvier 21, 2020 14:44 CET, Jesper Louis Andersen <jesper.louis.andersen@REDACTED> a écrit:
 On Mon, Jan 20, 2020 at 11:13 AM ludovic@REDACTED <ludovic@REDACTED> wrote:Hi, thank you, mnesia could actually be a good fit. I would have to ensure that the schema is created only once (so not being part of the docker container initialization) but that would be better than using tab2file after every write !
  The route I usually take is to create the schema and produce a FALLBACK.BUP file. You then attach persistent storage to your docker container and arrange that the storage starts out with the FALLBACK.BUP. On first startup, this file unpacks itself into your pristine mnesia schema. And from then on, you have persistent storage. It is usually fair easier to handle than trying to figure out if there is a schema and create it dynamically. There is a rough overview in the GraphQL tutorial I wrote a couple years back: https://shopgun.github.io/graphql-erlang-tutorial/#_mnesia (scroll up a bit and also read "Mnesia initialization" As for your problem: * Think about system_time vs monotonic time. You probably want to track system_time for jobs since monotonic is not persistence-safe, but this creates trouble with leap seconds.* Track UTC to avoid daylight saving time.* system_time requires you to handle NTP time jumps. At least monitor them and log them. Think about the warp mode you want for the Erlang node.* At 1000 entries, full scans to cancel stuff isn't a problem. If it ever becomes, store both {TS, K, V} and {K, TS} in the table. Then you can quickly cancel K.* One process is authoritative for the table. This guarantees serialization.* Spawn processes to handle K/V pairs. There are at most 1000 of them.* ordered_set is the way to go. If we have Now, you wake up and find every record with TS < Now up to a limit (25, say). You then handle those and remove them. Cycle 25 at a time, since this limits a spawn-spike if you suddenly have many timers going off at the same time. Especially important if your work is resource-intensive. You can use e.g., monitors to track the worker-count.  


 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200121/0c5064cc/attachment.htm>