search

unrolled / render

Go package for easily rendering JSON, XML, binary data, and HTML templates responses.
MIT License
1.94k stars 146 forks source link

Further improve locking #92

Closed zeripath closed 3 years ago

zeripath commented 3 years ago

As a second step improving #90, only lock when absolutely necessary and reconstruct functions to ensure that the current templates are referenced in the helper func instead of a global reference.

Signed-off-by: Andrew Thornton art27@cantab.net

zeripath commented 3 years ago

Basically there are two options here.

This one uses the standard RWMutex instead of Atomics which allows us to keep the mutex around for use in other situations - e.g. if we want to/need to lock on other parts of the Render in future we're going to need to keep a mutex around.

zeripath commented 3 years ago

I've closed #91 as I think this locking approach is better and allows us to use-fsnotify in the directory system.

lunny commented 3 years ago

It's better that the lock is only in the templates and not exposed to render. The templates could have init, lookup and compile methods.

And if development is a compile-time setting, we could have two implementations for templates to be lock free in production mode.

unrolled commented 3 years ago

@zeripath Can this one be closed now?

zeripath commented 3 years ago

yup can be closed!