[erlang-bugs] escript file operations fail on halt

[Michael Truog]

Just as an update: I found that my issue with file operations was not related to the file port driver not completing async thread jobs, which made more logical sense.  The fact remains that two things would have helped make the situation clearer:
1) clearly document the default flush operation for the erlang:halt/1 function
2) add an escript:exit/1 function which just calls erlang:halt/2 with flush == true as a convenience function (so that people are able to have simpler source code and not care about the halt/flush details).

Thanks,
Michael

On 05/18/2013 04:25 PM, Michael Truog wrote:
> Hi,
>
> There is an odd type of failure when:
> 1) async threads are enabled by default for the Erlang VM
> 2) an escript is used to spawn the Erlang VM
> 3) erlang:halt/1 is used to terminate the escript with a known error code
>
> The erlang:halt/1 and erlang:halt/2 code here:
> https://github.com/erlang/otp/blob/maint/erts/emulator/beam/bif.c#L3937
> Makes the default flush parameter false!  The default flush parameter is currently undocumented.  So, when an escript performs a file operation that depends on the async thread pool (based on the internal Erlang code and configuration) and then attempts to do erlang:halt(integer()), the file operations may not complete or perhaps only partially complete.  In my particular use case, I can observe a rename file operation getting stuck inbetween the actual completion of the rename (and I am not using anything but a normal/default Linux filesystem, not NFS).
>
> It seems important to change the default erlang:halt/1 behaviour for escript usage so that flush is true (I understand fail-fast probably means normal Erlang VM usage shouldn't have flush default to true).  An alternative is a new escript function that sets the flush option for the user (which is probably an easier solution to agree on) (e.g., escript:exit/1).
>
> Thanks,
> Michael