Reload schema definition on SIGHUP

[begriffs]

Fixes #475

I manually verified this works, but it's hard to think how to add an automated test.

[ruslantalpa]

maybe call it refDbStructure like in App.hs

[ruslantalpa]

I know there is no big chance for "race conditions" here but what are the advantages of IORef over MVar? My understanding is that MVar is a IORef with "locks attached"

[begriffs]

That's a good question about MVar vs IORef. The code on this branch initially used MVar, but it seemed like it wasn't adding any safety for the situation over IORef so I thought I'd use the simplest thing that works. The only perceived advantage is simplicity.

[ruslantalpa]

The question is for my own education, not that there is anything wrong with the code.
Simplicity how? In terms of API, mvar and ioref i think are similar. I am guessing you are referring to the underlying complexity of the ioref vs mvar libs?

[ruslantalpa]

Maybe another way to put it is "is there any time a good reason to use ioref vs mvar" and it seems there might be, some discussion about performance here (didn't look too closely) https://www.reddit.com/r/haskell/comments/39ef3y/ioref_vs_mvar_vs_tvar_vs_tmvar/

[begriffs]

IORef does less internally and is a little faster, not that it matters much. I found a good comparison between the two abstractions: 1, 2.

I think we should be safe from concurrency problems because I'm assuming db changes and sighup happen seldom whereas web requests happen often.

• If a sighup happens a split second before a web request it's no big deal if that request uses old state
• If many sighups happen very quickly it doesn't matter which one wins since the db probably hasn't changed structure during that time

Also MVar models the distinction of being full or empty, whereas our IORef obtains a value upon creation and it doesn't make sense for it to be "emptied."

[diogob]

I loved the pull request and the thread here, very informative :D