Re: Append-File

From: Mike Ghan <MikeGhan_at_logix-controls.com>
Date: Fri, 9 Sep 2005 10:09:47 -0700

Are you sure only one FORK (thread) is running? Does your main thread
(or any other thread) access the file? If so you'll need some sort of
synchronization so two threads do not simultaneously access the file.
Or you could redefine APPEND-FILE to open the file in shared mode.

Also, any write error will not close the file causing the next append to
fail. Additionally, if Timestamp causes any sort of stack imbalance,
you'll lose the file handle. I push the file handle to the return
stack, ex:

: WriteLog0 ( -- )
   S" Filename.exe" APPEND-FILE=20
   IF report-append-error
   ELSE >R TimeStamp R@ WRITE-FILE ( *write-ior )
      R> CLOSE-FILE
      IF report-close-error
      THEN ( *write-ior )
      IF report-write-error
      THEN
   THEN ;

Use CATCH simplifies this further

: DO-WRITE-LOG
   S" Filename.exe" APPEND-FILE THROW >R
   TimeStamp R@ WRITE-FILE ( *write-ior )
   R> CLOSE-FILE THROW
   ( *write-ior ) THROW ;

: WriteLog0 ( -- )
   ['] DO-WRITE-LOG CATCH ?DUP
   IF (THROW) report-error THEN ;
       =20

Mike=20

-----Original Message-----
From: sftalk-bounce_at_forth.com [mailto:sftalk-bounce_at_forth.com] On Behalf
Of Virgil Stamps
Sent: Wednesday, September 07, 2005 12:09 PM
To: SwiftForth Talk
Subject: [sftalk] Append-File

Maybe someone has experienced similar problems... I have been fighting =
=3D
this for over a month.

I am using APPEND-FILE and infrequently get an IOR exception.

: WriteLog0 ( --)
    DailyFN ZCOUNT APPEND-FILE \ ( a u -- fid ior )
    IF DROP 0 Z" LOG APPEND-FILE" INVALID-FILE-OP
    ELSE ( fid) DUP TimeStamp ROT WRITE-FILE
         IF DROP 0 Z" LOG WRITE-FILE" INVALID-FILE-OP
         ELSE ( fid) CLOSE-FILE
               IF DROP 0 Z" LOG CLOSE-FILE" INVALID-FILE-OP
               THEN
         THEN
    THEN
;

DailyFN always has a valid file name. The fid and ior returned when this
happens is -199 =3D3D (Can't open file). Is there a problem of APPENDING =
a
=3D file reported? Maybe something to do with using FORK ? Just
phissing...

Problem part 2:
A 3rd party Watch-Dog program has made me aware of infrequent 1st chance
exception Access Violations. An example:
The instruction at 0x775F515FB referenced memory at 0x000001AD. The =3D
memory could not be read.

I infrequently also get Second-chance exceptions which reports an =3D
attempt to write to a memory location. This causes the program to abort.

Is there a way to utilize the address reported to reference offending =
=3D
FORTH code? I try to trap everyway I know how and it never happens where
I am looking. I think it may be linked in with the file access problem
simply because it has the same sort of frequency.

Virgil Stamps
=3DA0 =3D20

----------------------------------------------------------------------
sftalk_at_forth.com The SwiftForth programming discussion email list
To unsubscribe, send subject "unsubscribe" to sftalk-request_at_forth.com
For list command help, send subject "help" to sftalk-request_at_forth.com
Message archives are located at http://www.forth.com/archive/sftalk
----------------------------------------------------------------------
This list is a forum for SwiftForth users. For product support and bug
reports, please send email to support_at_forth.com
----------------------------------------------------------------------

This archive was generated by hypermail 2.2.0 : Thu Dec 04 2008 - 03:04:20 PST