You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 4801 Reporter:@mshinwell Assigned to:@mshinwell Status: closed (set by @xavierleroy on 2011-05-29T10:19:57Z) Resolution: fixed Priority: normal Severity: minor Version: 3.11.0 Category: ~DO NOT USE (was: OCaml general) Related to:#6276 Monitored by: rdouglass sweeks @dbuenzli yminsky ogunden @mmottl
Bug 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.
This patch has been here a long time. Is it going to make its way into a release? We're currently maintaining our own patch, and would prefer to get it merged.
Original bug ID: 4801
Reporter: @mshinwell
Assigned to: @mshinwell
Status: closed (set by @xavierleroy on 2011-05-29T10:19:57Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 3.11.0
Category: ~DO NOT USE (was: OCaml general)
Related to: #6276
Monitored by: rdouglass sweeks @dbuenzli yminsky ogunden @mmottl
Bug 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.
File attachments
The text was updated successfully, but these errors were encountered: