rminnich@udel.EDU (Ron Minnich) (01/01/88)
Sorry to be so long in replying, but i have not had a chance to work on this for a while. For the record the problem was that i could not get io requests to work to internet.device after the first one- all the other requests always returned right away, before internet.device even got to look at them. For those of you who have been following this discussion: It looks like at some point- probably in the transition from 1.0 to 1.1- the definition of IO completion changed. Leo posted some notes from the 1.0 documentation that implied that an io transaction was considered complete when an io request got enqueueued on its ReplyPort. So to see if a request was complete 1.0 probably cdr'ed down the ReplyPorts Message list looking to see if the request's Message was a member of the list. This is kind of a high overhead operation it seems, so not surprisingly in 1.1 and later systems the definition changed. In 1.1 and later, a request is considered complete if: iorequest->io_Flags & QUICK is true, or iorequest->io_Message.mn_Node.ln_Type == NT_REPLYMSG So, whereas in 1.0 various state bits hanging around in a request could never matter, in 1.1 and later the driver had better make sure (one way or another) that if it is going to handle the request asynchronously it has to 1) clear the QUICK flag 2) Make sure the node type is NOT NT_REPLYMSG. In my case i was clearing the QUICK flag, but the node type was unchanged, and so as soon as i exited the device, WaitIo would see that 'it was done' (in its terms) and so do a Remove (removing it from the device driver's lists) and return with no error set. By the time internet.device got around to checking for requests it was long gone. And that was my problem. The solution for now (I am not sure i like this) is to simply jam NT_MESSAGE into the ln_Type structure member. Does that sound reasonable? Anyway, now internet.device is up to the next level of problems. Incidentally, the ONLY way to determine all this was to look at disassembled listings of amiga.lib. How depressing. This was the one machine I had sworn i would not do that with. Thanks to all of you who were kind enough to reply! -- ron (rminnich@udel.edu)