-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fwrite hangs if called from within mclapply #1727
Comments
Can't reproduce on OS X El Capitan, v1.9.7 latest. |
I just run it again (with data table downloaded right now), with same results, on two different Linux machines. I guess it might be an OS/compiler dependent issue? |
@rdiaz02 I am having the same problem on my debian machine. apart from fwrite, i also noticed other functions in data.table that if used in mclapply, R hangs. The cpu usage goes down to and stay at 0. |
I don't have the same problem on another old linux machine though. I guess it's probably caused by c libraries so I don't expect it will be resolved soon. I'd replace with fwrite with saveRDS at the moment. |
This sound like another case of implicit/explicit parallelisation conflict. Have you tried |
@ChristK @jangorecki thank you very much. I didn't know |
When calling fwrite from inside mclapply the execution hangs.
Here are two reproducible examples. The first uses a unique temporary file name via
tempfile
; the second doesn't.Identical to the above, but without the tempfile (we create a filename using the index of
mclapply
), to make sure that is not the problem:Expected behavior: run finishes without hanging, much like it does with write.
What does verbose in fwrite say? The runs show
What can I see if I look at the stuff that is written?
If I look at
afile1
andafile2
, in the run that hangs, the only thing that is outputed is the header, not the contents of the file.Output from sessionInfo()
Is the cause of problem that the object we are writing is the same?
I would not expect that to be an issue, but that is not the problem, because this happens even if we write different R objects (here, each call modifies the object before writing it):
The text was updated successfully, but these errors were encountered: