On 7 October 2014 14:55, Garth N. Wells <[email protected]> wrote:
>
> On Tue, 7 Oct, 2014 at 1:42 PM, Martin Sandve Alnæs <[email protected]>
> wrote:
>
>> On 7 October 2014 14:34, Garth N. Wells <[email protected]> wrote:
>> >
>> >
>> >
>> > On Tue, 7 Oct, 2014 at 10:35 AM, Jan Blechta <
>> [email protected]> wrote:
>> >>
>> >> On Tue, 7 Oct 2014 10:23:21 +0100
>> >> "Garth N. Wells" <[email protected]> wrote:
>> >>
>> >>>
>> >>> On 6 Oct 2014, at 16:38, Martin Sandve Alnæs <[email protected]>
>> >>> wrote:
>> >>>
>> >>> > I think this is the best solution:
>> >>> >
>> >>> > 1) Require the user to close file objects deterministically.
>> >>> > Relying on the del operator is not deterministic, we need to
>> support
>> >>> > .close() and/or __enter__/__exit__ for the with statement in
>> dolfin.
>> >>> >
>> >>>
>> >>> Sounds good. We can print a warning message from the File object
>> >>> destructors if a file is not closed (this can later become an error).
>> >>
>> >>
>> >> Good idea, but maybe warning could be issued from __del__ operator if
>> >> object was not properly destroyed/closed. In C++ layer everything is
>> OK.
>> >
>> >
>> > There are some advantages to insisting on explicit file opening/closing
>> in the C++ interface too, particularly in parallel, so we could reasonably
>> keep the interface consistent across Python and C++.
>> >
>>
>> I don't see any advantages? The standard way to handle this kind of thing
>> in C++ is to follow a RAII pattern.
>>
>
> Presently, VTK files are opened and closed behind the scenes at each
> write. A consequence is that if a program is killed the VTK output remains
> valid. With parallel IO via HDF5, a number of users have been bitten by
> XDMF/HDF5 data being corrupted when exiting early. If we make users
> consciously manage opening and closing of files, they are less likely to be
> bitten in the case of a premature program exit.
>
> Garth
I'm not convinced that's true. If we have a correct exception safe RAII
implementation that
_should_ be more robust w.r.t. closing files in the case of exceptions than
manual close() calls.
I'm all for _having_ flush and close functions in all file classes.
But in C++ the RAII concept is the standard way to manage resources,
and for good reasons: exception safety being one of them:
{
HDF5File file(name);
file.write(...);
foo(); // if this throws an exception...
file.write(...);
file.close(); // ... this won't execute
// .. but with RAII the file would be closed here, and that's the way all
standard conforming libraries work
}
just as Python users may want to write
with HDF5File(name) as file:
file.write(...)
foo(); # if this raises an exception...
file.write(...)
# the file is closed at the end here
These are patterns that really should follow the native language way.
Martin
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
