ast@cs.vu.nl (Andy Tanenbaum) (02/26/88)
It has been pointed out a couple of times that if FS is sending to tty and an interupt occurs that causes tty to run and try to send to FS, you get a deadlock. Can somebody post a nice short little test program that steps on this bug and hangs the system fairly consistently. I was planning to investigate it, but I can't make it happen on my system. Also, in response to a comment a couple of days ago, the Atari compiler is not limited to 64K, so if Atari people insist on going beyond the 64K + 64K limit, that software won't work on the PC. On the other hand, on a 512K Atari, one is so tight for physical memory, that people will automatically be careful. It is the people with 4 megabyte Mega-STs who will be the problem. Perhaps we will set the initial message of the day to: "Small is Beautiful" Andy Tanenbaum (ast@cs.vu.nl)
V050KY8G@ubvmsc.cc.buffalo.edu (02/28/88)
Well, I'm only working with V1.1 of the system now, but I notice one of the
things that tends to "hang" the system, at least temporarily, by tying up the
FS task is when ^S is typed on the console. I noticed this one day while
running a disk arm exerciser in the background ("&" on the end of the command
line) whilst examining a long file with cat. The first ^S I hit (to read around
a screenful) caused the FS to naturally wait for the TTY task to reply ("I am
done outputting those characters for you now"). Meanwhile, my hard disk arm
stopped (it was doing read()'s from /dev/hd2). A dump of the system (F2?)
showed the problem: FS waiting for a msg from TTY. Has this been corrected in
V1.2 of the system? I remember seeing a description in the DL section of
CompuServe something about a "multitasking FS"... was this implemented in 1.2?bing@galbp.LBP.HARRIS.COM (Bing Bang) (03/01/88)
In article <1234@louie.udel.EDU> V050KY8G@ubvmsc.cc.buffalo.edu writes: > I remember seeing a description in the DL section of >CompuServe something about a "multitasking FS"... was this implemented in 1.2? i've been working with a multi-tasking fs for some time now... here's a progress report. in my fs, all messages between fs and the tasks are handled asynchronously, except for those that involve a access to a file system. to do this without causing deadlocks i had to provide a system que for messages waiting to be sent. this means a sender will never get blocked. this change made possible running back ground processes even with the tty stopped on a foreground job. it also made it possible for me to do the following - inform() no longer exists. messages always get through - implementation of named pipes. i use it as a cheap ipc - implementation of global semaphores. i made them a special file that aquires the semaphore by reading from it and releases it by writing to it. no new system calls needed! :-) -tty signals go through fs who know who owns the tty. a compromise, but it works i really had to tear the guts out of fs. posting my work will be a major under- taking, besides i took stuff out that some people may still use, like the ram- disk (i boot onto a hard drive directly). but i am in the process of setting up a local bbs ("The MINIX Corner") which will have download capabilities. perhaps this is the solution... -- Bing H. Bang +--------------------------------------------------------+ Harris/Lanier |OS/2 on PS/2: Half an operating system on half a machine| Atlanta GA +--------------------------------------------------------+
wes@obie.UUCP (Barnacle Wes) (03/07/88)
In article <664@ast.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: > It is the people with 4 megabyte Mega-STs who will be the > problem. Perhaps we will set the initial message of the day to: > "Small is Beautiful" This is true, with a couple of notable exceptions, like data compression programs. The first that comes to mind is the 'compress' program in the NetNews distribution. It is difficult to compile a program with an 800K array on a system with 64K I+D spaces :-). -- /\ - "Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!utah-gr! / \/ \/\/ \ - Contend in Vain." - uplherc!sp7040! / U i n T e c h \ - Schiller - obie!wes