Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!decvax!wivax!cadmus!harvard!seismo!brl-tgr!tgr!bux@dual.uucp From: bux@dual.uucp Newsgroups: net.unix-wizards Subject: Re: v7 shared text bug & fix. Message-ID: <6561@brl-tgr.ARPA> Date: Sun, 9-Dec-84 13:57:47 EST Article-I.D.: brl-tgr.6561 Posted: Sun Dec 9 13:57:47 1984 Date-Received: Thu, 13-Dec-84 03:04:14 EST Sender: news@brl-tgr.ARPA Organization: Ballistic Research Lab Lines: 34 In reply to Joe Gurthridge's misunderstanding of the bug: >> I cannot find a problem. The flaws in the agrument seem to me to be: >> Fisrt,when you are busy writing out a shared text segment you are considered >> to have I/O in progress ........ you cannot be swapped out. This is not the case. It is quite possible to be swapped out in this instance. My first article followed the thread rather closely but I will summarize here for Joe's benefit. From xccdec(), a call to swap() is made to write out the text segment. If no swap buffers are availible, the process is put to sleep. There is nothing preventing the process at this point from being swapped out. >> Second, the above code prevents other processes from being scheduled, >> because their proc table entries still have a valid text pointer. Well this is indeed true. However, the case of interest is when one or more of these processes are already on the swapdev and then try to get back in. Again, this was explained in detail in my first article. I am not surprized that many machines may not experience the problem since it depends on some rather unlikely timing/loading. Several other fixes have been proposed and I have been made aware of the fact that this bug was posted to the net about 1 year ago(before my time!) David Buxbaum dual!bux@BERKELEY.ARPA {ihnp4,ucbvax,hplabs,decwrl,cbosgd,sun,nsc,apple,pyramid}!dual!bux Dual Systems Corporation, Berkeley, California