home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.unix.internals
- Path: sparky!uunet!psgrain!hippo!ucthpx!aim1!aim1!gram
- From: gram@aim1.aztec.co.za (Graham Wheeler)
- Subject: Re: The STREAMS scheduler
- Message-ID: <gram.715599461@aim1>
- Organization: Aztec Information Management
- References: <gram.714739169@aim1> <gram.714839766@aim1>
- Date: Fri, 4 Sep 1992 09:37:41 GMT
- Lines: 35
-
- gram@aim1.aztec.co.za (Graham Wheeler) writes:
-
- >Anyway, the trick was that there is a service request value in the
- >dual port memory as well, which is set by the card to hex FF when it
- >has handled the last request. So I now check this as well, and everything
- >seems to be fine.
-
- It turned out that this was *not* the case. Even though this fix worked,
- it shouldn't have! In the end, I scrapped the write-side service, put all
- the messages on my own singly linked list, and do the write side service
- from within the interrupt handler. So the interrupt handler looks like:
-
- ipibintr() {
- ind = dualPort->ind;
- status = dualPort->status;
- switch (ind) {
- /* Interrupt type-specific processing */
- }
- if (data waiting to be retrieved from card)
- retrieve data;
- if (card RPC not busy and message on list)
- remove message from list and do RPC;
- }
-
- It still locks up now and then, but I think that is a timing problem due
- to the use of spinlocks when retrieving data from the card. The RPC interface
- to the card is being redesigned to remove the spinlocks, and I will see what
- happens after that. I have removed the calls to splstr, as the consensys
- seems to be that this is not a Good Thing.
-
- --
- Graham Wheeler | "That which is weak conquers the strong,
- Software Systems Engineer/Student | that which is soft conquers the hard."
- Aztec Information Management/UCT | Lao Tzu - Tao Te Ching Ch. 78
- gram@aim1.aztec.co.za / gram@cs.uct.ac.za
-