Date: Fri, 10 Feb 1995 12:04:12 -0600 From: Mark Tinguely <tinguely@plains.nodak.edu> To: peter@bonkers.taronga.com, terry@cs.weber.edu Cc: davidg@Root.COM, hackers@FreeBSD.org, jmb@kryten.atinc.com Subject: Re: MIT SHM X11 extensions? (fwd) Message-ID: <199502101804.AA23116@plains.NoDak.edu>
next in thread | raw e-mail | index | archive | help
Terry says: > Uh, why is ETXTBUSY still around? because no one has taken the time to fix it right. I agree it should go. > What else would you do if you opened a currently running executable for > writing? Terry also says: > Actually, you could fault the whole image to swap and close the > reference to the file -- and just allow the write, with never an > ETXTBUSY to be seen. or keep the file in the filesystem and the vnode pager can refer to the correct vnode of text. the debate could be should we keep the swap backstore requirements small (local drives are small NFS servers are big or the local machines drives are getting bigger and can handle it). my bias is small swap backstore, big filesystems containing text. (of course the filesystem switch-a-roo response to the problem has difficulties when (time sequence): open execute open write (save old file -- any new executes will use this) close write open execute (should use new executable) open write (backup vnode pointer being used what now? make the backup vnode pointer an array?) ... we talked about this before on the net. the one consideration is should all executables be in swap, so that we can restart the apps where we stopped (notebook memory saver philosophy). or very least all NFS on swap because they are too dump to figure about writes. it would be stupid to re-work ETXTBUSY and then change it again. the underlining questions have not been solved, so nothing has been done. --mark.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502101804.AA23116>