You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed that unliftio's UnliftIO.Temporary doesn't lift temporary's System.IO.Temp, but instead reimplements most of that module.
As far as I understand, the main difference between both is that temporary will create the file/temporary template based on a random string, while unliftio will use the process's PID. This may actually have surprising behavior with concurrent programs (e.g., see this issue: UnkindPartition/temporary#8), where race conditions can happen. temporary mitigates this problem.
Is there any reason unliftio reimplements the module? Wouldn't it make it easier to keep up with updates in that library?
One more thing: why not re-export getCanonicalTemporaryDirectory?
The text was updated successfully, but these errors were encountered:
I've noticed that
unliftio
'sUnliftIO.Temporary
doesn't lifttemporary
'sSystem.IO.Temp
, but instead reimplements most of that module.As far as I understand, the main difference between both is that
temporary
will create the file/temporary template based on a random string, whileunliftio
will use the process's PID. This may actually have surprising behavior with concurrent programs (e.g., see this issue: UnkindPartition/temporary#8), where race conditions can happen.temporary
mitigates this problem.Is there any reason
unliftio
reimplements the module? Wouldn't it make it easier to keep up with updates in that library?One more thing: why not re-export
getCanonicalTemporaryDirectory
?The text was updated successfully, but these errors were encountered: