On Sep 24, 2010, at 1:16 AM, Simon King wrote:
Hi Justin!
On Sep 23, 11:55 pm, "Justin C. Walker" <[email protected]> wrote:
- If one has a big string s, then singular(s) will not directly
send s
to the singular interface, but eventually
singular._eval_line_using_file(s) is called.In that method, the file
singular._local_tmpfile() is opened for writing, s is written to it,
then it is closed.
- Directly after closing the file, it is read into Singular. I could
imagine that sometimes it is attempted to read it before closing it
succeeded.
- Moreover, if the next large input line occurs, then
singular._local_tmpfile() is again opened for writing -- perhaps
before the previous I/O to it was completed?
I would say, as we did in the 70's and 80's, that's a big 10-4.
... which, according to http://www.urbandictionary.com/define.php?
term=big%2010-4,
probably means that you enthusiastically agree? I am not a native
speaker.
That's a big 10-4 :-}
So, better before than afterwards. Makes sense.
Again, don't rely on things to happen exactly as you want them
to. The sync() call tells the system (maybe both python and the
kernel; not sure how it's implemented and what kind of cacheing
python does) that you want the data sent to its final resting
place. How that happens is up to a lot of "strategic" code that
lives in the kernel and perhaps in python. In general, think of
these calls as telling the underlying system "here's what I want
to happen", not "do this now and come back when you're done".
Is there a command that tests for a given file name whether or not
there are any I/O operations left to be done on that file? Such
command could then be put in a "while" loop.
No; I'm not even sure how one would implement such a thing in a way
that is guaranteed. For one thing, your disk hardware may be doing
the same thing (cacheing and buffering).
I doubt that it would be acceptable to slow down every single
call to
an expect interface by pausing.
The latter was more of a suggestion to try, with the hopes of
understanding more about what was going wrong. I didn't intend
that to be a fix.
OK.
One problem is: How can one debug it, and how can it be doctested once
it is fixed? The errors really occur only sporadically. It is like
"run the test suite of my cohomology spkg on t2.math, which takes
about 2 hours, and sometimes (but not always, and not always in the
same test example) you will see the error".
That is the crux of the problem. This is a race condition (multiple
outcomes, depending on the ordering of operations, many of which are
outside of your control. Debugging of these problems is why we pay
software developers the big bucks :-}
Seriously, there is very little science to debugging race conditions;
it's mostly art.
Justin
--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds
-----------
My wife 'n kids 'n dogs are gone,
I can't get Jesus on the phone,
But Ol' Milwaukee's Best is my best friend.
-----------
--
To post to this group, send an email to [email protected]
To unsubscribe from this group, send an email to
[email protected]
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
