If we can use the _r function this can allow us more stablity and less cost. A mutex, AFAIK, cost a bit.
Which is why it's cheaper NOT to unlock than to unlock. Now, using localtime_r anyway is fine, but it's questionable whether the lock should be released or not. I say that it probably shouldn't.
/ David Hedbor
Previous text:
2003-06-17 23:18: Subject: Re: Pike localtime(), threads safe and low level localtime() / localtime_r() ?
Le mardi, 17 jun 2003, à 22:40 Europe/Paris, Martin Stjernholm, Roxen IS @ Pike developers forum a écrit :
And why can't they reason the same way? They might have their own mutex like the interpreter mutex. Is it perhaps because they are embedded while Pike is not? But we'd like to make Pike embeddable, so if this specific issue is solved beforehand there'll be one less worry.
I can see no harm using localtime_r if it exists; if Xavier wants to fix that then it's ok with me.
Thanks Martin.
If we can use the _r function this can allow us more stablity and less cost. A mutex, AFAIK, cost a bit. If a function can have it's equivalent thread safe, then we should use it if possible instead of adding only a mutex...
My 0,02
/Xavier
/ Brevbäraren