🚀 go-pugleaf

[.........]

I would think the best solution would be to reserve seperate buffers for
each user if you have to maintain compatibility, as all the other solutions
I can think at the moment of have problems.  A system that allows you to  
dynamically configure the buffer space and assign different numbers of
buffers to each user or process might be useful.

I too, would like to hear any other proposed solution to the multiple
user buffer pool problem posed here.

Keith Doyle
#  {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd

In article <161@vger.UUCP> valencia@vger.UUCP writes:
>
>	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? [...]
>					Andy Valencia


I have a Z80 multiuser Forth, based on NVSS F83 Forth.  This and every other
multitasking Forth I have seen (including polyFORTH) will only change tasks
when a word PAUSE is executed.  All I/O and disk accessing words contain
PAUSE, especially in any ready-wait loops.  Essentually this means that the
address returned by the BLOCK word is valid until the next I/O word.  It is
the task's responsibility to move any data to a private storage area if it
needs to do I/O without possibly loosing the data.  The word ">TYPE" is used
in the words LIST INDEX, and within the editor to make sure an entire line
of a screen gets printed before the buffer gets swapped out.  It is defined: 
  : >TYPE SWAP OVER PAD SWAP CMOVE  PAD SWAP TYPE ;
(it moves the data to PAD before typing). 

Two block buffers are adequate.  If operating under a DOS, such that the
block buffers are associated with files, there are additional complications
is different tasks can refer to different files.

Tom Almy

How about this:

You have N buffers.  You have tasks A and B, among others.
When you switch from task A to task B you save the buffer
mapping table along with the other stuff.  Then when you
switch back to A you check to make sure that the buffers
have the same blocks in them.  If they don't you write 
out the changed ones and read back in the ones that A is
expecting. 

This is horrible if both A and B are making heavy use of
the buffers but if A is using them heavily and B not very
much then it isn't too bad.  And it is compatible.

Anyone see problems?
-- 
		Doug Collinge
		School of Music, University of Victoria,
		PO Box 1700, Victoria, B.C.,
		Canada,  V8W 2Y2  
		decvax!nrl-css!uvicctr!collinge
		decvax!uw-beaver!uvicctr!collinge
		ubc-vision!uvicctr!collinge