ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/05/90)
Category 2, Topic 1 Message 15 Fri Dec 22, 1989 R.BERKEY [Robert] at 05:37 PST To: Tom Almy Re: F83 multi-tasking TA> The only unfortunate aspect is that they had to cripple the TA> multitasker so that it couldn't be used in a multi-user TA> environment. But there is also a difference between multi-programmer and multi-user. For example, F83 could be used to implement a multi-user system for several data entry operators inputting data forms. Multi-programmer is a different story. I'm always more productive when I am free to crash the system, execute EMPTY-BUFFERS , run system diagnostics, change the disk(ette)s, etc. TA> ...they stole the multitasking technique from the company that TA> didn't want them to issue it multi-user. "Stole"? Just what do you mean? Are you saying that round-robin scheduling is proprietary to Forth, Inc.? Or that there is copyright violation? And that Forth, Inc., was involved in design decisions of F83? I'm not familiar with the history of the F83 multi-tasker, but didn't Perry publish it in the 1983 FORML proceedings? Robert Berkey ----- This message came from GEnie via willett through a semi-automated program. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
toma@tekgvs.LABS.TEK.COM (Tom Almy) (01/06/90)
In article <130.UUL1.3#5129@willett.UUCP> ForthNet@willett.UUCP (ForthNet articles from GEnie) writes: >But there is also a difference between multi-programmer and multi-user. For >example, F83 could be used to implement a multi-user system for several data >entry operators inputting data forms. Well, not easily. KEY and EMIT were not vectored through user variables, thus the terminal device would not change with different tasks. By changing these (and also user variable vectoring the cursor control function) processes could be assigned different terminals. In fact the editor worked just fine with multiple terminals of different types. This is how I got the printer spooler to work. The spooler task got its command input from a buffer that was filled via a command from another task (an interlock prevented filling the buffer unless the spooler task was idle). The printer task output device was bound to the invoking tasks so any error messages would be received by the appropriate user. Only the printer task was allowed to execute PRINTER to redirect output. >Multi-programmer is a different story. I'm always more productive when I am >free to crash the system, execute EMPTY-BUFFERS , run system diagnostics, >change the disk(ette)s, etc. I never said it was practical! The trick to doing it is to "fork" the FORTH vocabulary so each user has his/her own vocabulary head. > TA> ...they stole the multitasking technique from the company that > TA> didn't want them to issue it multi-user. >"Stole"? Just what do you mean? Are you saying that round-robin scheduling >is proprietary to Forth, Inc.? From what I understand (and this is not first hand information) Forth Inc. did/does considered its technique of round-robin scheduling proprietary. As you know, it uses self-modifying code to handle dispatching very quickly. Actually "stole" is probably too strong. As far as I know, they had permission to use the technique, providing it was crippled. Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply