Re-reading your explanation… it makes me wonder if what you’re really trying to do is create a global update tic for some frequent cron job. This is usually not the way you want to do things in an Erlang program. If you need updates, you usually want them to occur as a part of whatever process initiates a visible change and have the effect of that change come out the other end of the system as a result of execution. Erlang is a naturally “reactive” system, and nothing is shared. If you are writing a global tic to update something then the thing you are updating is also global… and that means you’re probably trying to share something you shouldn’t.
The only time you can’t avoid that is when you are dealing with an external resource that you have no possible way of listening to. For example, if I want to update a list of available files I have three options:
generate a fresh list any time a user asks for it (react to a user query only, but do the work multiple times)
build an index of files that I update every X seconds and deliver that to the user (react to a user query, but cache work)
update my cache whenever the filesystem notifies me of a change, and serve the cache whenever the user asks (react to both the user and the filesystem
The third model, where I react to both the filesystem and the user, with no timer involved, but also very little sequential work passing over all the same data again and again, is the one most suited to Erlang’s primitives.