54 lines
2.3 KiB
Plaintext
54 lines
2.3 KiB
Plaintext
2010-05-28
|
|
Cleanup of automatic regIOobject rereading.
|
|
|
|
- all files (usually only IOdictionary) that need to be monitored
|
|
should be registered using MUST_READ_IF_MODIFIED. The MUST_READ should
|
|
be used for objects that do not need to be re-read (e.g. fields).
|
|
In the old system it would actually monitor e.g. 0/U and constant/polyMesh
|
|
files.
|
|
I've temporarily added a warning in IOdictionary if constructed with MUST_READ.
|
|
Same for IOList,IOField,IOMap if constructed with MUST_READ_IF_MODIFIED
|
|
(or is rereading supported?). Please let me know if something does not work or
|
|
you see the warning
|
|
"Dictionary constructed with IOobject::MUST_READ instead of IOobject::MUST_READ_IF_MODIFIED." << nl
|
|
|
|
|
|
- any monitored and modified file will get reloaded from the exact path
|
|
that was monitored. In the old system it would/could do a re-search through all
|
|
times.
|
|
|
|
|
|
- all reductions to synchronise status on different processors are done with
|
|
a single reduction instead of one reduction per registered object. This could
|
|
be quite a gain on large numbers of processors.
|
|
|
|
|
|
- all file monitoring is done by an instance of 'fileMonitor' in the Time
|
|
class. The fileMonitor class can be found in OSspecific. Default is
|
|
to use the (linux-specific) 'inotify' system calls.
|
|
If compiled with -DFOAM_USE_STAT it will revert to the current 'stat' system
|
|
calls.
|
|
|
|
|
|
- inotify does not need timestamps. There is no need for fileModificationSkew
|
|
to allow for time differences. (there can still temporarily be a difference
|
|
in modified status between different processors due to nfs lagging)
|
|
|
|
|
|
- fileMonitor stores two hashtables per file so there is a small overhead
|
|
adding and removing files from monitoring.
|
|
|
|
|
|
- if runTimeModifiable is false at start of run no files will get monitored,
|
|
however if runTimeModified gets set to false during the run the files
|
|
will still get monitored (though never reloaded). This is only a hypothetical
|
|
problem in that the kernel still stores events for the monitored files. However
|
|
inotify is very efficient - e.g. it gets used to track changes on file systems
|
|
for desktop search engines.
|
|
|
|
|
|
- in the old system one could call modified() on any object and get
|
|
and uptodate state. In the new system it will return the state from
|
|
the last runTime++ (which if it triggered any re-reads will have reset the
|
|
state anyway).
|