Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!tuvie!inst182
From: inst182@tuvie (Inst.f.Techn.Informatik)
Newsgroups: comp.os.minix
Subject: Re: An FS idea - good or bad?
Message-ID: <1742@tuvie>
Date: 2 Aug 90 11:16:36 GMT
References: <1766@ccadfa.adfa.oz.au> <638@philica.ica.philips.nl>
Reply-To: inst182@tuvie.UUCP (Inst.f.Techn.Informatik)
Organization: Technical University of Vienna, EDP-Center
Lines: 33


adrie@philica.ica.philips.nl (Adrie Koolen) writes:

>A stated FS asks for a lot of rewriting. I think that most people are
>waiting for someone to post an easy and short solution, which can be
>patched quickly. I think that those people can wait long. A multi-threaded
>FS, with one FS code + data segment, but several (say 5) FS process entries
>in the kernel tables (proc[]), will not be the most beautiful solution
>but still an effective solution with not that many changes.

Good idea, and if you could make all those nasty global variables
[You see, I had a look at the (1.3) sources since I made the naive remark
that writing a stated FS wouldn't be hard to write] in the
FS local, all you would need is an extra stack for each thread (You need
this anyway) so that the threads can't disturb each other. All those
stacks would have to be in a single 64k segment with the data segment
(if you still need global data), but that should not be too much of a
problem. 

Another idea: It should be possible to have just one FS thread sitting
around all the time waiting for requests. Each time it receives a
request it spawns a thread to handle the request and waits for the next
request. If it cannot spawn the thread (Proc table full, out of memory,
...) it should handle the request itself, thus blocking any further
requests.

What do you think ?


|    _	| Peter J. Holzer			| Think of it	|
| |_|_)	| Technische Universitaet Wien		| as evolution	|
| | |	| hp@vmars.tuwien.ac.at			| in action!	|
| __/  	| ...!uunet!mcsun!tuvie!vmars!hp	|     Tony Rand	|