Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!agate!shelby!neon!lucid.com!pab
From: pab@lucid.com (Peter Benson)
Newsgroups: comp.sys.mac.programmer
Subject: Re: doing real work at interrupt(Was:Breaking the rules (Was:More Mac Wierdness...))
Message-ID: <2303@heavens-gate.lucid.com>
Date: 30 Oct 90 18:26:20 GMT
References: <1990Oct30.152816.2172@cs.umu.se>
Organization: Lucid, Inc. Menlo Park, CA
Lines: 23
In-reply-to: dvlmfs@afrodite.cs.umu.se's message of 30 Oct 90 15:28:16 GMT


It seems like what is needed is a general mechanism whereby any sort of
task can be initiated at interrupt level.  This would have to be done by
apple, but the right hing to have is a call that effectively says "call
this function with these arguments at the next possible opportunity."

"The next possible opportunity" would be right away if no uninterruptible
operations were in progress, or it would be at the end of the ongoing
uninterruptible operation.  At the system level all this requires is
knowing exactly what operations are uninterruptible, setting a flag at the
beginning of them, and checking a queue at the end of them.  Also the queue
needs to be maintained in an atomic fashion.  There would be times when it
would just fail (queue is full, or another queue operation already in
progress) , but it can certainly return a status to indicate that.  There
would have to be some restrictions on what kind of data could be passed in
too, since direct pointers to movable memory would be an obvious no-no.

I'm pretty new to Mac hacking.  Maybe something somewhat like this already
exists.  Is there a problem with this.  Could it be done with lots of
patches?

-ptr-
pab@lucid.com