Hi, Simon, On Sep 23, 2010, at 15:38 , Simon King wrote:
> On 24 Sep., 00:04, "Justin C. Walker" <jus...@mac.com> wrote: >> For most unix-like systems, it's generally not true that a close() of a file >> descriptor will wait until the file is closed. > > Thank you, that's good to know! Then it seems more than likely to me > that there's the problem with the expect interface. Agreed; see below. >>> Would it make sense to call os.fsync(F) after F.close()? >> >> I would think that doing this will only cause an error of some sort to be >> handed to your code: 'F' is not associated with anything after the close, so >> "os.sync(F)" would be essentially meaningless to the kernel. > > Sure, I meant to catch the ValueError that is raised when the file > really is done. > > But do I understand correctly that os.sync(F) will either raise a > ValueError orr wait until F.close() is completed? I can't say for sure, not having looked at the code, but I think it's a safe bet that when F.close() returns, the internal (Python) state shows that file structure as no longer usable. Therefore, it doesn't matter what the state of the "external-to-python" file is; as far as python code is concerned, it's closed. The sync() call will have either no effect (maybe returning an EISCLOSED-type error) or throw an exception. My guess is the former, but the manual (which I haven't checked) should say for sure. >> To your problem with corruption, if you are opening a new file descriptor >> for a file that you are writing with an existing file descriptor, you are >> asking for trouble, ... > > It is not *I* who is asking for trouble here: The code that I posted > above is from sage/interfaces/expect.py. Well, I was referring to the generic, lower-cost, more-widely-available 'you' :-} >> You write to the file descriptor >> Python holds onto the data for a while >> You open a new descriptor on the same file >> Python reads in what's there > > I guess that is exactly what's happening in the Gap, Singular,... > interfaces: > > - 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. >> I don't know enough about the rest of the system or your code to be sure >> this is what's happening. If you haven't already, try F.sync() (or >> os.sync(F)) before closing the file. > > 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". >> Another hack: try pausing before accessing the file after the close, so >> you're (more) sure that the close has had an effect before proceeding. > > 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. >From your description above, it sounds pretty much like you know what is going >wrong and where. Delay loops might help verify it, but that's all they are >good for. Cheers, Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Absorption of Federal Funds -------- Men are from Earth. Women are from Earth. Deal with it. -------- -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
