[plt-scheme] Make multiple attempts to open DrScheme join running process?

On Feb 25, Todd O'Bryan wrote:
> On Sun, 2007-02-25 at 01:33 -0500, Eli Barzilay wrote:
> > On Feb 24, Todd O'Bryan wrote:
> > > As I've mentioned before, I'm running DrScheme in a thin terminal
> > > lab and have 30 students sharing one server.
> > 
> > On a single machine?  I don't think that it's possible.
> > 
> It really is: http://www.ltsp.org/
> 
> I have one $2000 machine (dual dual-core Opterons with 4GB of RAM)
> serving 30 stations that each cost $130 (not including monitor,
> keyboard, and mouse). If you do the math, that's 30 stations for
> about $200 each. The set-up usually works pretty well, even when I
> have 20 students all using Eclipse at once. Unfortunately, the whole
> thing breaks down when the system starts to thrash, and it's only
> been doing that, so far, in my intro classes where I use DrScheme.

Well, one obvious solution is to get another sever into the cycle -- a
reasonable machine (no screen, video etc) should not add more than $30
per workstation...

BTW, thrashing is more likely with DrScheme, since you get a very
small amount of shared memory -- most of it is individual per process.
I don't know how Eclipse does in that department.

BTW#2, an interesting idea to try (if MrEd had this capability) is to
start a single MrEd process and inside that run several DrScheme
instances, each on a different display...


> I've already used the PLT_ONLY (or similar, not at school to check)
> environment variable that Robby (I think) suggested to reduce the
> memory footprint required for a single student, but students can
> still bring down the machine. I don't know much about system
> administration, but I think one of the foundational principles is
> that users should not be able to, whether through malice or
> stupidity, be able to screw up the system for everybody else. :-)

That works either in theory, or given enough administration effort.
(Run a Unix-into course, and right after students learn how to fork
processes things become interesting.)

The problem is that the default setup for all OSs (including Linux)
assumes a single user -- so when you run a lot of stuff the system
will try hard to just run that stuff while slowly grinding itself to
uselessness.  One easy way to solve your problem (assuming that you
have enough resources for running 30 drschemes at the same time) is to
put limits on how much ram each student gets (see
http://www.seifried.org/security/index.php/Linux_Limiting_and_Monitoring_Users
for examples).  This way they can't run another drscheme (since the
limit you'll put will not be enough for two).  Another thing that I
would do (together with limits) is change drscheme to be a script that
checks if there is a running mred process that the current user has,
and barf if this is the case (so they know why it doesn't work, rather
than complaining that something is broken).


> > > Students seem to be in the very bad habit of double-clicking
> > > files to open them, not realizing that (I think) this spawns a
> > > new DrScheme process and eats up lots of memory.
> > > 
> > > Is there any way to have subsequent calls to DrScheme (well, the
> > > drscheme binary) check for a running version for the given user
> > > and open a new tab with the file if there is one, or open a new
> > > instance if not.
> > 
> > It should do this on Windows.  I'm not sure about OSX, but on Unix
> > it's very difficult to arrange such things (and not even desirable
> > in many cases).
> 
> Isn't this what Firefox does? From the man page: [...]

Yes it does, and it uses exactly the kind of stuff I'm talking about.
In FireFox's case, it looks like it uses orbit, which is openning a
socket file which is used to communicate with the running process.
Another popular way of doing this is through some X messages.  In both
cases, this is the kind of functionality that is hard to get to work
across many unix implementations, and MrEd is a "very native" unix
application (relies of very common X and Unix stuff).


> Plus, it's just embarrassing that a whole class can run a Java
> program like BlueJ without making the server thrash while a
> relatively Linux/Unix native program like DrScheme seems to have
> problems in a multi-user environment. [...]

Of course not -- in the same way that it's not embarrassing to be able
to run so much less Java code than C code, etc etc.  (If you use
assembler, then one of these $130 boxes will be able to run all
student programs at the same time...)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!