HP3000-L Archives

October 2001, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Wirt Atmar <[log in to unmask]>
Reply To:
Date:
Thu, 4 Oct 2001 12:23:58 EDT
Content-Type:
text/plain
Parts/Attachments:
text/plain (30 lines)
David asks:

> Why not just have the "watching" process delay (max expected transfer time
* (
> 1 + safety factor)) between detecting the file and accessing it -

Even doing this still makes the procedure an asynchronous process that still
possesses a window of time that would allow for things to get screwed up.
John Pickering's solution (transmitting a second small "trigger" file) is
exactly the right thing to do when the condition that Greg Stigers mentioned
occurs (the file name appears in the dictionary before the file transfer is
actually completed).

John's solution has two advantages: the first is that it's fully synchronous,
and in the choice between synchronous and asynchronous solutions, always
choose synchronous. In fact, fifty years of experience by tens of thousands
of engineers and programmers have produced this very simple rule: "Never use
an asynchronous solution."

The second is that it's quicker, and potentially much quicker. If a "safety
factor" time is to be tacked onto any watcher program's behavior, that safety
time has to go to infinity if you want the probability of a screwup to drop
to zero. Rather than wait any amount of time at all, once the "trigger" file
shows up, you instantly know that you're safe to proceeed.

Wirt Atmar

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2