On Thu, 2008-08-21 at 17:34 -0400, Jim Davidson wrote:
> So, technically this was a case where
> we dynamically created code which was later read by ADP (which had the
> same dev/inode cache stuff as fastpath). However, this was done
> carefully:
>
> -- Tcl-level mutex/condition variables to ensure only one thread did
> the "hard" work even if several were interested in the result
> -- Careful write to a non .adp extension, unique temp file
> -- Atomic rename in place when ready
>
> It was a combination of traditional atomic Unix filesystem semantics
> and newer thread synchronization at the Tcl level used to avoid ever
> getting some mutant result.
Here is an example using Tcl level commands (although a hidden use of
mutex/condition vars:
# save datastore to file
# Note: a data.tmp file is created. If writing to this
# succeeds, this is renamed to the data file, hopefully
# atomically replacing it
# Note2: the data.tmp file is not a lock file, it is used
# to avoid a half written file in the event of power loss
# or process exit.
proc ::datastore::save { store } {
....
set LockID [lock $store]
if {[catch {
set FD [open ${dataFileroot}.tmp w+]
fconfigure $FD -translation binary -encoding binary
puts $FD "$out"
close $FD
file rename -force ${dataFileroot}.tmp $dataFileroot
} err ]} {
unlock $store $LockID
error $err "::datastore::save error saving store $store"
}
unlock $store $LockID
}
But it is very difficult (impossible) to safely read/write files unless
you can synchronize access (you need cooperation) and/or use atomic
file operations (serialize access). The above example uses both.
tom jackson
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
