Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!andrew.cmu.edu!bader+ From: bader+@andrew.cmu.edu (Miles Bader) Newsgroups: comp.sys.amiga.tech Subject: Re: PIPE: and AmigaDOS bug (was Re: SKsh 1.4 comments) Message-ID: Date: 3 May 90 17:27:08 GMT References: <90May1.074656edt.2589@ois.db.toronto.edu> , <223@mtiame.oz> Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA Lines: 23 In-Reply-To: <223@mtiame.oz> jep@mtiame.oz (Jesper Peterson) writes: > |It seems AmigaDOS can be fooled to load a handler TWICE. > |Theory: > | TEE needs pipe: > | Dos finds out that it has to load pipe: and starts loading it > | Meanwhile TYPE needs pipe: and dos again finds out that pipe: has to > | be loaded. Dos doesn't know that it is doing this already and starts > | loading the pipe handler for the second time. > | The result is that TEE is talking to one pipe: and TYPE to another. > A *really* well behaved handler should probably Delay() then check if > it is already in the device list and abort if it finds "itself". > In reality you don't do this of course, so you are correct in your analysis > when you suggest it is a race condition. The system should hold a lock while it checks to see if the device is there, and if it finds that it's not, put a dummy entry in the device list that just says "It's being loaded", then release the lock and proceed to load the device. Any other tasks that find the dummy entry while they're looking for the device can just block until it gets loaded (using whatever mechanism, I don't know what it would be). -Miles