Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!haven!decuac!shlump.nac.dec.com!shodha.dec.com!elvira!ridder
From: ridder@elvira.enet.dec.com (Hans Ridder)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Determining disk devices
Keywords: Auto-disk reading, drive contention
Message-ID: <612@shodha.dec.com>
Date: 16 Jan 90 22:49:13 GMT
References: <2924@dogie.macc.wisc.edu> <572@shodha.dec.com> <485@dsoft.UUCP>
Sender: news@shodha.dec.com
Organization: Digital Equipment Corporation, Customer Support Center
Lines: 32

In article <485@dsoft.UUCP> groo@dsoft.UUCP (Bill Squier) writes:
>In article <572@shodha.dec.com> ridder@elvira.enet.dec.com (Hans Ridder)
>writes:
>>Something I thought of a while back was that a file requester could
>>*automatically* select a volume when it was inserted.  The assumption
>>would be that if you just stuck it in, you probably want to access it.
>
>That's a bad idea on a multitasking machine.  How would the process know
>that there wasn't some other application that you were inserting the
>disk for.

How about using the IDCMP messages that tell you when your window is
activated or deactivated (WINDOWACTIVATED and WINDOWDEACTIVATED?  Hell
I don't remember).  If you're the current window, then the disk is for
you! 

>Even worse, what if all applications followed this strategy?  Imagine
>the disk contention as VirusX, ProcessA, ProcessB, ProcessC, and the
>validator all started reading the disk at once!

OK, so then there would be three processes.  The validator (which will
exit soon since the bit-map is valid, right?), VirusX (I don't know
how long this takes to exit since I don't use it), and the active
window.  That won't be too bad, will it?

Yes, floppies suck don't they!

-hans
========================================================================
  Hans-Gabriel Ridder			Digital Equipment Corporation
  ridder@elvira.enet.dec.com		Customer Support Center
  ...decwrl!elvira.enet!ridder		Colorado Springs, CO