aboutsummaryrefslogtreecommitdiffstats
path: root/erts/emulator/beam/erl_ao_firstfit_alloc.c
diff options
context:
space:
mode:
authorBjörn Gustavsson <[email protected]>2016-03-29 09:10:13 +0200
committerBjörn Gustavsson <[email protected]>2016-04-04 14:37:15 +0200
commit5ae46e823a8a52ed4e5b960ff62975894b1a8302 (patch)
treeb782b23d89d388ad4daa922ebc4ddea269802e35 /erts/emulator/beam/erl_ao_firstfit_alloc.c
parent1244cebc4b369cfd53ae775ea7380c61ed98ed64 (diff)
downloadotp-5ae46e823a8a52ed4e5b960ff62975894b1a8302.tar.gz
otp-5ae46e823a8a52ed4e5b960ff62975894b1a8302.tar.bz2
otp-5ae46e823a8a52ed4e5b960ff62975894b1a8302.zip
Handle multi-giga byte writes to files
Test cases that write 4Gb to a file at once would fail on OS X and FreeBSD. By running a simple test program on OS X (El Capitan 10.11.4/Darwin 15.4.0), I found that writev() can handle more than 4Gb of data, while write() only can handle less than 2Gb. (Note that efile_drv.c will use write() if there is only one element in the io vector, and writev() if there is more than one.) It is tempting to attempt to piggy-back on the existing mechanism for segmenting write operations in efile_drv.c, but because of the complex code I find it too dangerous, both from a correctness and performance perspective. Instead do the change in unix_efile.c, which is considerably simpler.
Diffstat (limited to 'erts/emulator/beam/erl_ao_firstfit_alloc.c')
0 files changed, 0 insertions, 0 deletions