Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005106OCamlotherlibspublic2010-07-18 06:562016-12-07 17:45
Assigned To 
PlatformOSOS Version
Product Version3.10.2 
Target VersionlaterFixed in Version 
Summary0005106: Two channels sharing a file descriptor fail to seek properly due to buffering
DescriptionIt's possible to get two separate channels (an in_channel and an out_channel) to share the same operating-system-level file descriptor by using Unix.openfile in O_RDWR mode and then calling both Unix.in_channel_of_descr and Unix.out_channel_of_descr. I did this because it seemed like the intuitive way of getting hold of a file in a proper way for reading and writing simultaneously.

I expected this to end with a single file pointer shared between the two channels, but at least for them to work properly as long as you were careful to always seek a channel before using it.

Unfortunately, this is not the case because the standard library adds some buffering to in_channel, and omits making the OS-level lseek() call in cases when a seek can be satisfied within the buffer. This means that if you (1) do a bit of reading with the in_channel, (2) seek a long way away with the out_channel and do some writing, and then (3) seek the in_channel back close to where you were reading earlier, then what happens is that the call to seek_in omits the lseek() syscall due to being satisfied in the buffer, but as you start reading, you run off the end of the buffer... but then the attempt to refill the buffer reads from the last place you *wrote*, because no lseek() was done!
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
doligez (administrator)
2012-09-19 11:52
edited on: 2014-07-31 15:02

A possible fix would be to flush the buffer at each seek operation, but how much slower will other programs get?

doligez (administrator)
2014-07-31 15:03

A better solution is to call lseek even if the seek is within the buffer, but you can still get the wrong data when the buffers overlap.
shinwell (developer)
2015-05-06 21:56

Damien and I talked about this. It seems that a proper solution to this problem may be fairly complicated, probably involving tracking of all buffers pointing to a given file descriptor, and maybe involving some management to prevent them overlapping.

- Issue History
Date Modified Username Field Change
2010-07-18 06:56 Hawk777 New Issue
2011-05-20 18:15 doligez Status new => acknowledged
2012-07-10 20:10 doligez Target Version => 4.01.0+dev
2012-07-31 13:36 doligez Target Version 4.01.0+dev => 4.00.1+dev
2012-09-19 11:52 doligez Note Added: 0008109
2012-09-19 11:52 doligez Target Version 4.00.1+dev => 4.01.0+dev
2013-08-19 11:58 doligez Target Version 4.01.0+dev => 4.01.1+dev
2014-05-25 20:20 doligez Target Version 4.01.1+dev => 4.02.0+dev
2014-07-31 15:02 doligez Note Edited: 0008109 View Revisions
2014-07-31 15:03 doligez Note Added: 0011952
2014-07-31 15:03 doligez Target Version 4.02.0+dev => 4.02.1+dev
2014-09-04 00:25 doligez Target Version 4.02.1+dev => undecided
2014-09-26 19:36 doligez Target Version undecided => 4.02.2+dev / +rc1
2015-05-06 21:56 shinwell Note Added: 0013851
2015-05-06 21:56 shinwell Target Version 4.02.2+dev / +rc1 => 4.02.3+dev
2015-07-15 15:32 doligez Target Version 4.02.3+dev => 4.03.0+dev / +beta1
2015-12-03 13:26 frisch Target Version 4.03.0+dev / +beta1 => later
2016-12-07 17:45 shinwell Category OCaml general => OCaml otherlibs
2017-02-23 16:42 doligez Category OCaml otherlibs => otherlibs

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker