Path: utzoo!dciem!nrcaer!sce!graham
From: graham@sce.carleton.ca (Doug Graham)
Newsgroups: comp.os.minix
Subject: Re: Recap on past 2 weeks
Message-ID: <888@sce.carleton.ca>
Date: 3 Aug 90 04:09:16 GMT
References: <7217@star.cs.vu.nl>
Organization: Systems & Computer Eng. Dept.,Carleton University,Ottawa,Canada
Lines: 57

In <7217@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>news, snail mail, and most recently FAXes.  If Andy Warhol's ghost ever
>offers you the chance to be famous for 15 minutes, try to bargain for less
>time.

Ah, I see. So *that* was the purpose of your message.

>First, FS.  There is no way I am ever going to muck up FS just to adding
>multithreading.

Hmmm, no swapping, no virtual memory, no multithreading ...
I sure wish the GNU people would hurry up.  I wonder what'll
become of MINIX when GNU OS hits the streets?  (I hope some
of us are still alive to find out)

>in a limited number of circumstances.  MINIX is intended for personal
>computers.

I though MINIX was intended as a teaching system.  Isn't it important
that students learn how a real world OS works? Some of them might
even work on one someday.

>If you have a foreground and a background job, and one of them is CPU bould
>while the other is I/O bound, there is similarly no gain.  The only gain
>comes when there are two or more I/O bound jobs, statistically not common,

Try running a make in the background and doing *anything* in the foreground.
I sure notice the difference.  But why would anyone want to do that anyway?
Why do you think so many people are concerned about improving the throughput
of FS?  Is it possible that they just might have noticed a problem?

>but possible.  I am not at all enthusiastic about making the code unreadable
>and buggy to optimize the performance of a relatively rare case.

Well then, *don't* make the code unreadable and buggy.
(A smartass answer I know, but I really don't see why adding threads is
going to create all the problems you're projecting.)

> What I MIGHT consider doing (then again, I might not), is this.

I realize you're a busy man, and probably don't have a lot of time to
be making major changes to MINIX, but it seems to me that there are enough
keen MINIX hackers out there to do the work. You only have to give the
go ahead, and maybe coordinate a bit.

>With relatively little effort, the disks could use this existing mechanism.
[use SUSPEND and REVIVE as with TTY I/O]
>How does that sound?

Like you haven't thought it through.  A number of people on comp.os.minix
have pointed out problems with this method while you were gone.  Unless
you've got some secret tricks up your sleeve, I can't see how this could
fail to be much more unreadable and buggy than using threads. It would
also require major changes to most of FS which threads would not.

--
Doug.