On Tue, 7 Oct, 2014 at 2:12 PM, Martin Sandve Alnæs
<[email protected]> wrote:
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.
I thought the issue we're discussing is that the above Python pattern,
which is the natural way to do things, can break in parallel because of
non-deterministic garbage collection and that we need an alternative?
Garth
Martin
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
