#13826: Race condition in star_imports cache
--------------------------------+-------------------------------------------
Reporter: vbraun | Owner: GeorgSWeber
Type: defect | Status: needs_review
Priority: critical | Milestone: sage-5.5
Component: build | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Volker Braun | Merged in:
Dependencies: | Stopgaps:
--------------------------------+-------------------------------------------
Changes (by nbruin):
* cc: robertwb (added)
* reviewer: Nils Bruin =>
* status: needs_work => needs_review
Comment:
OK, I don't know what we're supposed to do with whitespace anymore. I hope
someone else can sign off on that.
Concerning the caching strategy: I'm not so sure the current code is
particularly safe in the face of now-current development practices: If a
cache file is present and contains an entry for a module that a lazy star
import of that module will use that entry to initialize the namespace. I
don't think the cache ever gets updated should it be discovered the data
is out-of-sync.
The cache-file is only specific to the "branch" of sage. Now that people
mostly use mercurial queues, the branch name hardly identifies the
particular sage version. In particular, if I apply a patch that changes a
lazily imported module, the cache will not be marked as stale and I will
continue working with that. The cache will be resaved upon startup (see
`all.py`), but only the entries of modules that weren't in the cache
before will be updated, because the cache is blindly trusted for the other
ones.
I don't quite know what the best solution is. Perhaps `sage -b` should
just always mark the cache as invalid (i.e., delete it)? In that case,
`sage -b` should perhaps create the cache as well. In that case, there is
no need to rewrite the cache every time and there's no race condition
either.
It means that the cache would only reflect the sage "system library" and
would need to be located somewhere in the tree rather than in a user's
`.sage`. The problem is that in general the only way to know if the cache
is stale is by looking at the modification dates of the module files and
once we're statting all of those, we've lost what we were trying to gain.
For the sage library we can reasonably assume that only `sage -b` changes
that, so there we can cache state without having to stat.
I realize that this is escalating the scope of this ticket a bit, but if
`lazy_import` lies about objects available in the to-be-imported namespace
(due to using a stale cache), we have a rather critical problem. I'm
including Robert on the CC here in the hope he can explain why the current
approach is safe.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13826#comment:11>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
