book "Haskell Data Analysis Cookbook" by Nishant Shukla

I believe there is a non-thread safe code fragment in Chapter 1(page 15): import System.Directory (doesFileExist) ..... exist <- doesFileExist filename -- these two lines are non-thread safe .. yes?? to be thread-safe the above line and the following line would have to be together atomic .... input <- if exists then readFile filename else return "" ........... Vasili

On Sat, Jul 12, 2014 at 7:54 PM, Vasili I. Galchin
-- these two lines are non-thread safe .. yes?? to be thread-safe the above line and the following line would have to be together atomic ....
Not even then would it really be safe; it should trap the exception from readFile failing, instead of checking existence in a separate step. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

that was exactly my point ... I.e. if between two lines the "Haskell
thread-of-execution" is interrupted ... and another thread/process ...
.deletes the file then 2nd "line" of code would cause an exception to
be thrown ... i.e. because of non-existence .. . Brandon, aren't we
saying the same thing ... if so, forgive, my English .. :-)
Vasya
On Sat, Jul 12, 2014 at 7:02 PM, Brandon Allbery
On Sat, Jul 12, 2014 at 7:54 PM, Vasili I. Galchin
wrote: -- these two lines are non-thread safe .. yes?? to be thread-safe the above line and the following line would have to be together atomic ....
Not even then would it really be safe; it should trap the exception from readFile failing, instead of checking existence in a separate step.
-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

It is not the same thing, really, unless I'm misunderstanding. AFAIK there
is no straightforward way of making the combined check-if-exists-and-delete
block atomic at the bearsden level, even if you force serial execution at
the haskell level, and the established solution is to forgo the existence
check altogether, relying on the delete call to throw when the file doesn't
exist.
On Jul 13, 2014 2:32 AM, "Vasili I. Galchin"
that was exactly my point ... I.e. if between two lines the "Haskell thread-of-execution" is interrupted ... and another thread/process ... .deletes the file then 2nd "line" of code would cause an exception to be thrown ... i.e. because of non-existence .. . Brandon, aren't we saying the same thing ... if so, forgive, my English .. :-)
Vasya
On Sat, Jul 12, 2014 at 7:02 PM, Brandon Allbery
wrote: On Sat, Jul 12, 2014 at 7:54 PM, Vasili I. Galchin
wrote: -- these two lines are non-thread safe .. yes?? to be thread-safe the above line and the following line would have to be together atomic ....
Not even then would it really be safe; it should trap the exception from readFile failing, instead of checking existence in a separate step.
-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Mon, Jul 14, 2014 at 1:40 AM, Tobias Dammers
It is not the same thing, really, unless I'm misunderstanding. AFAIK there is no straightforward way of making the combined check-if-exists-and-delete block atomic at the bearsden level, even if you force serial execution at the haskell level, and the established solution is to forgo the existence check altogether, relying on the delete call to throw when the file doesn't exist.
Yes; this is my point, there is no way to make the separate check atomic. It's going to be two system calls which will allow task switching at syscall entry and thereby allow a race against another process; no amount of careful critical section handling within the process can stop this. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
participants (3)
-
Brandon Allbery
-
Tobias Dammers
-
Vasili I. Galchin