|View Issue Details [ Jump to Notes ] ||[ Issue History ] [ Print ] |
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004801||OCaml||~DO NOT USE (was: OCaml general)||public||2009-05-21 13:33||2014-01-03 01:36|
|Assigned To||shinwell|| |
|Product Version||3.11.0|| |
|Target Version||Fixed in Version|| |
|Summary||0004801: calls to lseek() don't release the runtime lock|
|Description||There are various calls to lseek() in the runtime, and none of these currently release the runtime lock. I have witnessed this causing the runtime to block for unacceptable periods when the seek is occurring on an NFS mount whose server is heavily loaded.|
I'm currently testing the attached patch. I'm guessing this might be too late for 3.11.1, but it would be great if the issue could be fixed there.
This patch has two consequences which affect the runtime's behaviour: first, it is of course now possible for a Caml thread context switch to occur in the middle of the affected channel functions. I don't think this is going to affect anything except code that is potentially broken anyway. Secondly, along the same lines, it is now necessary to take care with the Bigarray memory-mapping function to ensure that the fd being mmapped isn't disrupted in some way by a Caml function in another thread during [caml_ba_map_file]. This seems a reasonable restriction -- after all, you could as it is just truncate the file from some other C thread which would have a similar effect even without this patch.
|Tags||No tags attached.|
|Attached Files|| lseek.diff [^] (6,510 bytes) 2009-05-21 13:33 [Show Content]