octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: wait_for_file ?? [who/what/where does fclose()?]


From: Michael D Godfrey
Subject: Re: wait_for_file ?? [who/what/where does fclose()?]
Date: Fri, 10 Sep 2010 12:49:35 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100907 Fedora/3.1.3-1.fc13 Thunderbird/3.1.3

On 09/10/2010 12:26 PM, John W. Eaton wrote:
So, back to the question I asked yesterday:

  What were the specifics of the case(s) that were failing?  What types
  of systems, filesystems, etc.?  If it only occurred on network mounted
  filesystems that have the async option set, then I guess I'm not
  surprised by the failure.

  If the problem also happened on local filesystems, or NFS filesystems
  with the sync option set, then I'm not sure why it would happen, or
  how to avoid the problem.

I think we need to understand why the original failure that prompted
this discussion occurred.

An additional thought is that if these failures only happened on
network mounted filesystems that have the async option set, then I'm
not sure we should work too hard at tring to fix all the potential
problems that can occur with that option.  It's probably better to
recommend that people avoid using the option, or if they do and odd
failures happen, then it is not Octave's fault.

jwe
John,

I am at least partly to blame for this.   I noticed problems using ssh, with
or without NFS being involved.  But, the case that I tried to focus on was
when running Octave in an NX window on a server which had all local
storage (no NFS involved).  This is a simpler case than anything with
NFS (note that it is not just async, but also whether "hard" mount option is
used and whether NFS locking is working, and...)

So, the NX case has shown this problem because the drawing time
to the screen, particularly for graphics, can be very long when compared to a
local real screen or even X11 remotely.  And, or course, I focused on NX
as we use it all the time these days.  In the NX case, the original failure
was due to the fact that the sequence:

drawnow("eps", fid)
system("gs .......  option referencing .eps file generated by drawnow'")

had the effect that the drawnow did not even do the fopen("*.eps") by the
time the gs command was run.   Trying to put in a test of whether the drawnow
had written the eps file was very unreliable since drawnow, in fact, tended to
wait until Octave returned to the command prompt before creating the eps file.
Shai reports that there is no way to convince fltk to do the file write synchronously.
It does it "when it decides to."

The pipe mechanism appears to be working and, as you pointed out, is
a cleaner and more efficient way of doing this.

Oh, I should mention the NX normally uses ssh as its client-server protocol, but
this is really not relevant except that it is part of the timing issue.  NX is VERY
reliable, even on low bandwidth DSL.

Does this help?
Michael


reply via email to

[Prev in Thread] Current Thread [Next in Thread]