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

[Shai Ayal]

On Fri, Sep 10, 2010 at 10:49 PM, Michael D Godfrey
<address@hidden> wrote:
> 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.
>
I think the point here is not that the file system has long latencies
and is asynchronous, but by using NX, the X server becomes async and
with long latencies. Since drawnow depends on fltk redraws and this in
turn depends on X server request redrawing and such. A highly
optimized X server such as NX might do all sort of interesting
manipulation on the messaging between the X server and client.
So my guess would be that a lot of this confusing timings are because
of NX. perhapse Michael could check the same with just simple X11
forwarding of ssh (ssh -X) which will still give us high latency, but
no optimizations.

Shai