|
From: | Michael D Godfrey |
Subject: | Re: wait_for_file ?? |
Date: | Fri, 03 Sep 2010 09:53:57 -0700 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100806 Fedora/3.1.2-1.fc13 Thunderbird/3.1.2 |
On 09/03/2010 09:34 AM, John W. Eaton wrote:
This seems reasonable to me. But, there is an issue that needs, forIf so, then instead of generating a file and dealing with possible race conditions, how about doing something like if (postprocess_with_gs) fid = popen (gs command); else if (send_to_printer) fid = popen (lpr_command); else if (write_to_postscript_file) fid = fopen (ps_file_name); else error ("???"); endif feval (backend_print_function, fid, opts); me, explanation. In __ghostscript__.m around lines 100, the following happens: fid =fopen(offsetfile, "w"); ........ fflush(fid); (I added that in test code) status = fclose(fid); ## status returned is zero. If I add following the fclose(fid); the statement: fopen(offsetfile, "r"); it fails with file not found. Inspection of the file (in tmp) and a time and date stamp in the code shows that the file existed at the time of the fopen that failed. While I think that John's suggestion is liklely a better approach, it would still be helpful to find out why this simple fopen(xx,"w"); ... write something... fflush(); fclose(); fopen(), sequence fails. There should be no race condition in this. Michael Just for the record, my test output is: fflush(fid) of /tmp/oct-aPPXZ6.ps returned 0 After close: 03-Sep-2010 09:38:39 status: 0 error on fopen /tmp/oct-aPPXZ6.ps ls -l --full-time /tmp/oct-aPPXZ6.ps -rw-rw-r-- 1 godfrey godfrey 97 2010-09-03 09:38:39.000000000 -0700 /tmp/oct-aPPXZ6.ps |
[Prev in Thread] | Current Thread | [Next in Thread] |