Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 4/15/85; site vger.UUCP
Path: utzoo!utcs!lsuc!pesnta!parallel!vger!valencia
From: valencia@vger.UUCP
Newsgroups: net.lang.forth
Subject: Multi-user and files
Message-ID: <161@vger.UUCP>
Date: Thu, 9-May-85 15:20:30 EDT
Article-I.D.: vger.161
Posted: Thu May  9 15:20:30 1985
Date-Received: Fri, 10-May-85 12:35:18 EDT
Organization: UC Santa Cruz, CIS Dept.
Lines: 21
Keywords: loss, block files


	I've just finished writing a multi-tasking FORTH for the Z-80.
Like so many before, I held off on the disk drivers until the system
was more or less debugged. Then I came across what ends up being an
interesting question in FORTH philosophy: exactly how DOES one do the
FORTH memory buffering scheme? If you go back to "original" FORTH, you
end up depending on "block", and it gives you back a nice address: your
block buffer. Problem is, when you go multi-tasking, you have to start
wondering exactly how long it'll be before that buffer is re-used for
some other process' buffer.

	If you use some sort of locking mechanism, you run into the
the problem that your software is not compatible with the great
majority of FORTH software. Defining BLOCK so that it saves into a
user-specified buffer has the same problem, but also demands that
some number of 1K blocks are set aside--on a 64K system, how many
of those do you REALLY want around? So you poly-forth hackers, what
sorts of solutions exist for this?

					Interested,
					Andy Valencia